BR112018012185B1 - Terminal de rádio, método em um terminal de rádio, meio legível por computador não transitório e estação de rádio - Google Patents
Terminal de rádio, método em um terminal de rádio, meio legível por computador não transitório e estação de rádio Download PDFInfo
- Publication number
- BR112018012185B1 BR112018012185B1 BR112018012185-1A BR112018012185A BR112018012185B1 BR 112018012185 B1 BR112018012185 B1 BR 112018012185B1 BR 112018012185 A BR112018012185 A BR 112018012185A BR 112018012185 B1 BR112018012185 B1 BR 112018012185B1
- Authority
- BR
- Brazil
- Prior art keywords
- type
- communication architecture
- message
- ran
- rrc
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 221
- 238000004891 communication Methods 0.000 claims abstract description 528
- 230000006854 communication Effects 0.000 claims abstract description 528
- 230000005540 biological transmission Effects 0.000 claims abstract description 94
- 230000001413 cellular effect Effects 0.000 claims abstract description 20
- 230000004044 response Effects 0.000 claims description 23
- 230000011664 signaling Effects 0.000 abstract description 10
- 230000006872 improvement Effects 0.000 abstract description 4
- 101100087393 Caenorhabditis elegans ran-2 gene Proteins 0.000 description 251
- 210000004027 cell Anatomy 0.000 description 65
- 238000010586 diagram Methods 0.000 description 49
- 101150069124 RAN1 gene Proteins 0.000 description 33
- 238000012545 processing Methods 0.000 description 31
- 101100150273 Caenorhabditis elegans srb-1 gene Proteins 0.000 description 18
- 238000012546 transfer Methods 0.000 description 18
- 230000008569 process Effects 0.000 description 15
- 230000008859 change Effects 0.000 description 14
- 230000007704 transition Effects 0.000 description 12
- 230000006870 function Effects 0.000 description 11
- 238000007726 management method Methods 0.000 description 7
- 230000008901 benefit Effects 0.000 description 6
- 238000005259 measurement Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 230000005465 channeling Effects 0.000 description 4
- 238000004590 computer program Methods 0.000 description 3
- 230000010354 integration Effects 0.000 description 3
- 239000000725 suspension Substances 0.000 description 3
- 230000001052 transient effect Effects 0.000 description 3
- 210000000678 band cell Anatomy 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 2
- -1 CIoT BS Proteins 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 230000003321 amplification Effects 0.000 description 1
- 238000013144 data compression Methods 0.000 description 1
- 230000006837 decompression Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000003199 nucleic acid amplification method Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000001228 spectrum Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/12—Setup of transport tunnels
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/20—Manipulation of established connections
- H04W76/27—Transitions between radio resource control [RRC] states
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
- H04W8/24—Transfer of terminal data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/02—Terminal devices
- H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
- H04W28/18—Negotiating wireless communication parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/11—Allocation or use of connection identifiers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
Abstract
terminal de rádio, estação de rádio, nó de rede núcleo e método nos mesmos. um terminal de rádio (1) é configurado para transmitir, para uma estação de rádio (2), uma mensagem de configuração de conexão de controle de recurso de rádio (rrc) completada incluindo um elemento de informação de assistência ue indicando qual dentre uma pluralidade de tipos de arquitetura de comunicação para a transmissão de pacotes de dados referentes à internet celular das coisas (ciot) se deseja utilizar, suportar ou configurar. como resultado disso, por exemplo, com relação ao procedimento de comunicação específico envolvendo a determinação da arquitetura de comunicação a ser utilizada para um terminal de rádio servindo como um dispositivo ciot, é possível contribuir para o aperfeiçoamento da eficiência do procedimento de comunicação, para a redução de mensagens de sinalização, ou para a seleção de uma rede núcleo adequada.
Description
[0001] A presente descrição refere-se a um sistema de comunicação de rádio que suporta uma pluralidade de tipos de arquitetura de comunicação para transmissão de dados.
[0002] No Projeto de Parceria de 3a. Geração (3GPP), a padronização da Internet Celular das Coisas (CIoT) já estava em andamento. A CIoT pretendida em 3GPP inclui IoT de banda estreita (NB-IoT) e Máquina para Máquina melhorada de Evolução de Longo Termo (LTE eMTC). As características de LTE eMTC e NB-IoT incluem consumo de energia por Equipamento de Usuário (UE) ultrabaixo, um maior número de dispositivos por célula, espectros de banda estreita, e coberturas estendidas. Em LTE eMTC (categoria M), é especificado que a largura de banda de Frequência de Rádio (RF) UE de recepção seja de 1,4 MHz. Enquanto isso, em NB-IoT, é considerado que uma taxa de pico para downlink e uplink seja de 200 kbps ou 144 kbps para otimiza-ção de custo, reduzindo o consumo de energia, e estendendo a cobertura adicionalmente, e largura de banda RF UE tem cerca de 200 kHz (largura de banda efetiva de 180 kHz) para ambos uplink e downlink.
[0003] A literatura de não patente 1 descreve várias soluções de arquitetura de comunicação para transmissão de dados pequenos de forma infrequente em NB-IoT. Essas soluções incluem a arquitetura para a transmissão de dados através de um plano de controle (Solução 2), e arquitetura para a transmissão de dados através de um plano de usuário envolvendo a suspensão e retomada de uma conexão RRC (Solução 18). Na literatura de não patente 1, o suporte da Solução 2 é obrigatório para ambos o UE e a rede, enquanto que o suporte para a Solução 18 é opcional para ambos o UE e a rede.
[0004] A solução 2 é baseada em arquitetura de rede núcleo leve (CN) para CIoT. Na arquitetura CN leve, em consideração de casos de uso típico para dispositivos CIoT, uma rede núcleo suporta apenas um número limitado de funções, em comparação com o número das mesmas em entidades CN, de acordo com a LTE existente (isso é, uma Entidade de Gerenciamento de Mobilidade (MME), um Circuito de Acesso Servidor (S-GW) e um Circuito de Acesso de Rede de Dados em Pacote (P-GW)). A figura 1 ilustra a arquitetura de rede para CIoT em um caso sem roaming.
[0005] O Nó de Circuito de Acesso Servidor CIoT (C-SGN) é uma nova entidade de rede lógica. C-SGN é um nó CN possuindo ambos um plano de controle (CP) e um plano de usuário (UP). C-SGN fornece um procedimento de Gerenciamento de Mobilidade limitado (MM) para dispositivos CIoT, um procedimento de transmissão de dados pequenos, um procedimento de segurança para transmissão de dados pequenos, e um encerramento de uma interface SGi para o caso sem roaming. A função P-GW pode ser separada de C-SGN. Nesse caso, uma interface S5 é utilizada entre C-SGN e P-GW. No caso de roaming, C-SGN fornece uma interface S8.
[0006] A interface S1-lite é uma versão otimizada de S1-C (S1- MME). A interface S1-lite suporta as mensagens de Protocolo de Aplicativo S1 (S1AP) necessárias e elementos de informação (IEs) para os procedimentos CIoT e suporta os procedimentos de segurança otimizados. Para a transmissão eficiente de dados pequenos, os dados de usuário são distribuídos através da camada S1AP.
[0007] Especificamente, no caso de transmissão de dados pequenos Originados de forma Móvel (MO) para o caso de não roaming, o UE transmite uma mensagem de Extrato de Não Acesso (NAS) em uplink portando um pequeno pacote de dados (por exemplo, Protocolo de Internet (IP), não IP, ou serviço de mensagem curta (SMS)). Essa mensagem NAS de uplink chega a C-SGN através da Estação Base CIoT (BS CIoT). A mensagem NAS de uplink é transmitida em um Suporte de Rádio de Sinalização (SRB). Portanto, não é necessário se configurar um Suporte de Rádio de Dados (DRB). Adicionalmente, a segurança do Extrato de Acesso (AS) pode ser omitida.
[0008] C-SGN descriptografa a mensagem NAS de uplink para obter o pacote de dados pequenos. C-SGN envia o pacote de dados pequenos de acordo com o tipo de dados do pacote de dados pequenos. Para dados pequenos IP, C-SGN envia os mesmos através da interface SGi. Para SMS, C-SGN envia os mesmos para uma entidade relacionada com SMS (por exemplo, Centro de Permuta de Serviços Móveis de Circuito de Acesso SMS (SMS-GMSC), Centro de Permuta de Serviços Móveis de Intertrabalho SMS (SMS-IWMSC) ou roteador SMS). Para dados pequenos não IP, C-SGN envia os mesmos para a Função de Exposição de Capacidade de Serviço (SCEF).
[0009] No caso de transmissão de dados pequenos Encerrados de forma Móvel (MT) para o caso de não roaming, C-SGN envia uma mensagem NAS de downlink portando um pacote de dados pequenos para o UE através da BS CIoT. Qualquer DRB não é exigido para transmissão de pacote de dados pequenos em downlink e a segurança AS pode ser omitida.
[00010] BS CIoT ilustrada na figura 1 é uma estação base localizada em uma Rede de Acesso de Rádio CIoT (RAN CIoT). Um eNB LTE que é configurado para ser conectado a C-SGN pode ser utilizado no lugar de BS CIoT ilustrada na figura 1. Esse eNB LTE pode ser um eNB que suporta LTE eMTC.
[00011] Enquanto isso, a arquitetura, de acordo com a solução 18, fornece a transmissão de dados pequenos com pouca frequência no plano de usuário. A arquitetura de acordo com a solução 18 possui a característica de reutilização de informação obtida a partir da conexão RRC anterior para a configuração de conexão RRC, reduzindo, assim, o número de sinalizações exigidas para a transição de estado do Controle de Recurso de Rádio (RRC) UE.
[00012] Especificamente, um UE entra no modo RRC Inativo a partir do modo RRC conectado e retém a informação sobre a conexão RRC (por exemplo, um Contexto de Segurança de Extrato de Acesso, informação relacionada com suporte (incluindo informação de estado RoHC) e parâmetros L2/1 quando aplicável) enquanto está no modo RRC Inativo. De forma similar, um eNB retém informação sobre a conexão RRC do UE (por exemplo, o Contexto de Segurança de Extrato de Acesso, informação relacionada com suporte (incluindo a informação de estado RoHC), e parâmetros L2/1, quando aplicável). Adicionalmente, o eNB e uma MME retêm os Contextos UE S1AP. Adicionalmente, o eNB retém os endereços de túnel S1-U.
[00013] Quando o UE retorna para o modo RRC Conectado, o mesmo envia uma Solicitação de Retomada de Conexão RRC para o eNB. O eNB restaura um DRB, um contexto de segurança, uma conexão S1AP, e um túnel S1-U com base na informação retida previamente sobre a conexão RRC. Adicionalmente, o eNB notifica a MME sobre a mudança de estado do UE utilizando uma nova mensagem S1AP (isso é, Contexto S1-AP UE Ativo). A MME muda o estado do Gerenciamento de Conexão (ECM) do Sistema de Pacote Evoluído (EPS) do UE para o estado ECM Conectado, e então, envia uma mensagem Modificar Solicitação de Suporte para um S-GW. Como resultado disso, S-GW reconhece que o UE está no estado conectado e, dessa forma, entra em um estado no qual S-GW pode transmitir dados em downlink para o UE.
[00014] Na solução 18, um UE pode retornar para RRC Conectado e ECM Conectado sem transmitir uma mensagem NAS (isso é, Solicitação de Serviço). Adicionalmente, em comparação com o procedimento de configuração de conexão RRC de legado, as mensagens RRC a seguir podem ser removidas: - Configuração de Conexão RRC Completa; - Comando de Modo de Segurança RRC; - Modo de Segurança RRC Completo; - Reconfiguração de Conexão RRC; e - Reconfiguração de Conexão RRC Completa.
[00015] A literatura de não patente 2 descreve que um UE pode decidir, durante o procedimento de anexação, qual dentre a arquitetura da solução 2 e arquitetura da solução 18 o mesmo deseja utilizar. Adicionalmente, a literatura de não patente 2 descreve que um procedimento AS ou NAS pode incluir informação para permitir que a rede selecione a solução 2 ou a solução 18 para a transmissão de dados.
[00016] Literatura de Não Patente 1: 3GPP TR23.720 V1.2.0 (201511), "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements for Cellular Internet of Things (Release 13)", novembro de 2015
[00017] Literatura de Não Patente 2: 3GPP R2-156645, Qualcomm Incorporated, "NB-IoT SA2 architecture implications", 3GPP TSG RAN WG2 #92, Anaheim, EUA, 16 a 20 de novembro de 2015
[00018] Os inventores estudaram a arquitetura de comunicação para CIoT e a arquitetura de comunicação para reduzir o consumo de energia dos terminais de rádio e se depararam com vários problemas. Por exemplo, as literaturas de não patente 1 e 2 falham em descrever um procedimento específico para a determinação de um tipo de arquitetura a ser utilizado para a transmissão de pacotes de dados para um UE dentre uma pluralidade de tipos de arquitetura de comunicação (por exemplo, soluções 2 e 18). Os inventores estudaram os procedimentos de comunicação específicos envolvendo a determinação (ou seleção) da arquitetura de comunicação utilizada para um UE servindo como um dispositivo CIoT e conceberam vários aperfeiçoamentos que contribuem, por exemplo, para a melhoria da eficiência dos procedimentos de comunicação, redução de mensagens de sinalização ou seleção CN adequada.
[00019] Adicionalmente, a literatura de não patente 1 e 2 não considera suficientemente a mobilidade dos UEs servindo como dispositivos CIoT. A mobilidade dos dispositivos CIoT inclui uma mudança de célula no modo inativo (por exemplo, RRC Inativo) (isso é, a mobilidade de modo inativo) e uma mudança de célula no modo conectado (por exemplo, modo RRC Conectado) (isso é, mobilidade de modo conectado). Os inventores conceberam vários aperfeiçoamentos para procedimentos de mobilidade para dispositivos CIoT.
[00020] Um dos objetivos a serem alcançados pelas modalidades descritas aqui é fornecer um aparelho, método e programa que contribuam para a melhoria da eficiência de um procedimento de comunicação, redução das mensagens de sinalização ou seleção adequada de CN, com relação a um procedimento de comunicação específico envolvendo a determinação (ou seleção) da arquitetura de comunicação utilizada para um UE servindo como um dispositivo CIoT. Deve-se notar que o objetivo descrito acima é meramente um dentre os objetivos alcançados pelas modalidades descritas aqui. Outros objetivos ou problemas e características de novidade se tornarão aparentes a partir da descrição a seguir e dos desenhos em anexo.
[00021] Em um primeiro aspecto, um terminal de rádio inclui uma memória e pelo menos um processador acoplado à memória. O pelo menos um processador é configurado para transmitir para uma estação de rádio uma mensagem de solicitação de conexão de Controle de Recurso de Rádio (RRC) incluindo uma causa de estabelecimento ou outro elemento de informação indicando qual dentre uma pluralidade de tipos de arquiteturas de comunicação para a transmissão de pacote de dados, referente à Internet Celular das Coisas (CIoT), o terminal de rádio deseja utilizar, o terminal de rádio suporta ou com o qual o terminal de rádio está configurado em conjunto.
[00022] Em um segundo aspecto, um método em um terminal de rádio inclui a transmissão para uma estação de rádio de uma mensagem de solicitação de conexão de Controle de Recurso de Rádio (RRC) incluindo uma causa de estabelecimento ou outro elemento de informação indicando qual, dentre uma pluralidade de tipos de arquiteturas de comunicação para a transmissão de pacote de dados, referentes à Internet Celular das Coisas (CIoT), o terminal de rádio deseja utilizar, o terminal de rádio suporta, ou com o qual o terminal de rádio foi configurado.
[00023] Em um terceiro aspecto, uma estação de rádio inclui uma memória e pelo menos um processador acoplado à memória. O pelo menos um processador é configurado para receber uma mensagem de solicitação de conexão de Controle de Recurso de Rádio (RRC) a partir de um terminal de rádio. O pelo menos um processador é adicionalmente configurado para recuperar, a partir da mensagem de solicitação de conexão RRC, uma causa de estabelecimento ou outro elemento de informação indicando qual dentre uma pluralidade de tipos de arquiteturas de comunicação para transmissão de pacote de dados, referência à Internet Celular das Coisas (CIoT), o terminal de rádio de- seja utilizar, o terminal de rádio suporta, ou com o qual o terminal de rádio foi configurado.
[00024] Em um quarto aspecto, um método em uma estação de rádio inclui: (a) o recebimento de uma mensagem de solicitação de conexão de Controle de Recursos de Rádio (RRC) a partir de um terminal de rádio; e (b) a recuperação, a partir da mensagem de solicitação de conexão RRC, de uma causa do estabelecimento ou outro elemento de informação indicando qual dentre uma pluralidade de tipos de arquiteturas de comunicação para transmissão de pacote de dados, referente à Internet Células das Coisas (CIoT), o terminal de rádio deseja utilizar, o terminal de rádio suporta, ou com o qual o terminal de rádio está configurado.
[00025] Em um quinto aspecto, um terminal de rádio inclui uma memória e pelo menos um processador acoplado à memória. O pelo menos um processador é configurado para transmitir para uma estação de rádio uma mensagem de configuração de conexão de Controle de Recurso de Rádio (RRC) completa incluindo um elemento de informação de assistência UE indicando qual dentre uma pluralidade de tipos de arquitetura de comunicação para a transmissão de pacote de dados, com referência à Internet Celular das Coisas (CIoT), o terminal de rádio deseja utilizar, o terminal de rádio suporta, ou com o qual o terminal de rádio foi configurado.
[00026] Em um sexto aspecto, um método em um terminal de rádio inclui a transmissão para uma estação de rádio de uma mensagem de configuração de conexão de Controle de Recurso de Rádio (RRC) completa incluindo um elemento de informação de assistência UE indicando qual dentre uma pluralidade de tipos de arquiteturas de comunicação para a transmissão de pacote de dados, com referência à Internet Celular das Coisas (CIoT), o terminal de rádio deseja utilizar, o terminal de rádio suporta, ou com o qual o terminal de rádio foi confi- gurado.
[00027] Em um sétimo aspecto, uma estação de rádio inclui uma memória e pelo menos um processador acoplado à memória. O pelo menos um processador é configurado para receber uma mensagem de configuração de conexão de Controle de Recurso de Rádio (RRC) completa a partir de um terminal de rádio. O pelo menos um processador é adicionalmente configurado para recuperar, a partir da mensagem de finalização da configuração de conexão RRC, um elemento de informação de assistência UE indicando qual dentre uma pluralidade de tipos de arquiteturas de comunicação para transmissão de pacote de dados, com referência à Internet Celular das Coisas (CIoT), o terminal de rádio deseja utilizar, o terminal de rádio suporta ou com o qual o terminal de rádio está configurado.
[00028] Em um oitavo aspecto, um método em uma estação de rádio inclui: (a) o recebimento de uma mensagem de finalização de configuração de conexão de Controle de Recurso de Rádio (RRC) a partir de um terminal de rádio; e (b) a recuperação, a partir da mensagem de finalização de configuração de conexão RRC, um elemento de informação de assistência UE indicando qual dentre uma pluralidade de tipos de arquiteturas de comunicação para a transmissão de pacote de dados, com referência à Internet Celular das Coisas (CIoT), o terminal de rádio deseja utilizar, o terminal de rádio suporta, ou com o qual o terminal de rádio foi configurado.
[00029] Em um nono aspecto, uma estação de rádio inclui uma memória e pelo menos um processador acoplado à memória. O pelo menos um processador é configurado para receber uma mensagem de finalização de configuração de conexão de Controle de Recurso de Rádio (RRC) a partir de um terminal de rádio. O pelo menos um processador é adicionalmente configurado para, quando um segundo tipo de arquitetura de comunicação, no qual um pacote de dados é trans- mitido através de um plano de usuário, é selecionado para ser utilizado para o terminal de rádio dentre uma pluralidade de tipos de arquiteturas de comunicação, referentes à Internet Celular das Coisas (CIoT), gerar uma mensagem UE inicial incluindo uma mensagem de Extrato de Não Mensagem (NAS) inicial, recuperada a partir da mensagem de finalização de configuração de conexão RRC, e um identificador de ponto final de túnel de downlink utilizado no segundo tipo de arquitetura de comunicação. O pelo menos um processador ainda é adicionalmente configurado para transmitir a mensagem UE inicial para uma rede núcleo.
[00030] Em um décimo aspecto, um método em uma estação de rádio inclui: a) o recebimento de uma mensagem de finalização de con-figuração de conexão de Controle de Recurso de Rádio (RRC) de um terminal de rádio; b) quando um segundo tipo de arquitetura de comunicação no qual um pacote de dados é transmitido através de um plano de usuário é selecionado para ser utilizado para o terminal de rádio dentre uma pluralidade de tipos de arquitetura de comunicação, referentes à Internet Celular das Coisas (CIoT), gerando uma mensagem UE inicial, a mensagem UE inicial incluindo uma mensagem de Extrato de Não Acesso (NAS), recuperada a partir da mensagem de finalização de configuração de conexão RRC e um identificador de ponto final de túnel de downlink utilizado no segundo tipo de arquitetura de comunicação; e c) a transmissão da mensagem UE inicial para uma rede núcleo.
[00031] Em um décimo primeiro aspecto, um nó de rede núcleo inclui uma memória e pelo menos um processador acoplado à memória. O pelo menos um processador é configurado para receber uma men- sagem UE inicial de uma estação base. A mensagem UE inicial inclui uma mensagem de Extrato de Não Acesso (NAS), transmitida a partir de um terminal de rádio, e um elemento de informação indicando um tipo de arquitetura de comunicação determinado pela estação de rádio dentre uma pluralidade de tipos de arquiteturas de comunicação para a transmissão de pacote de dados referentes à Internet Celular das Coisas (CIoT). O pelo menos um processador é adicionalmente configurado para determinar com base no elemento de informação, o redi- recionamento da mensagem NAS inicial para uma rede núcleo correspondendo ao tipo de arquitetura de comunicação determinada. O pelo menos um processador ainda é adicionalmente configurado para transmitir para a estação de rádio uma mensagem de solicitação de mensagem NAS de redirecionamento indicando que a mensagem NAS inicial deve ser redirecionada para a rede núcleo correspondente.
[00032] Em um décimo segundo aspecto, um método em um nó de rede núcleo inclui: a) o recebimento de uma mensagem UE inicial a partir de uma estação base, a mensagem UE inicial incluindo uma mensagem de Extrato de Não Acesso (NAS) inicial transmitida a partir de um terminal de rádio, e um elemento de informação indicando um tipo de arquitetura de comunicação determinado pela estação de rádio dentre uma pluralidade de tipos de arquitetura de comunicação para a transmissão de pacote de dados referentes à Internet Celular das Coisas (CIoT); b) a determinação, com base no elemento de informação, do redirecionamento da mensagem NAS inicial para uma rede núcleo correspondendo ao tipo de arquitetura de comunicação determinado; e c) a transmissão para a estação de rádio de uma mensagem de solicitação de mensagem NAS de redirecionamento indicando que a mensagem NAS inicial deve ser redirecionada para a rede nú- cleo correspondente.
[00033] Em um décimo terceiro aspecto, um nó de rede núcleo inclui uma memória e pelo menos um processador acoplado à memória. O pelo menos um processador é configurado para receber uma mensagem UE inicial a partir de uma estação base. A mensagem UE inicial inclui uma mensagem de Extrato de Não Acesso (NAS) inicial, transmitida a partir de um terminal de rádio, e um elemento de informação indicando qual dentre uma pluralidade de tipos de arquitetura de comunicação para a transmissão de pacote de dados referentes à Internet Celular das Coisas (CIoT), o terminal de rádio deseja utilizar, o terminal de rádio suporta, ou com o qual o terminal de rádio está configurado. O pelo menos um processador também é configurado para determinar, com base no elemento de informação, um tipo de arquitetura de comunicação a ser utilizado para a transmissão de pacotes de dados para o terminal de rádio. O pelo menos um processador é adicionalmente configurado para determinar o redirecionamento da mensagem NAS inicial para uma rede núcleo correspondendo ao tipo de arquitetura de comunicação determinado. O pelo menos um processador ainda é adicionalmente configurado para transmitir para a estação de rádio uma mensagem de solicitação de mensagem NAS de redirecionamen- to indicando que a mensagem NAS inicial deve ser redirecionada para a rede núcleo correspondente.
[00034] Em um décimo quarto aspecto, um método em um nó de rede núcleo inclui: a) o recebimento de uma mensagem UE inicial a partir de uma estação base, a mensagem UE inicial incluindo uma mensagem de Extrato de Não Acesso (NAS) inicial, transmitida a partir de um terminal de rádio e um elemento de informação indicando qual dentre uma pluralidade de tipos de arquitetura de comunicação para a transmissão de pacote de dados referentes à Internet Celular das Coisas (CIoT), o terminal de rádio deseja utilizar, o terminal de rádio suporta, ou com o qual o terminal está configurado; b) a determinação, com base no elemento de informação, de um tipo de arquitetura de comunicação a ser utilizado para a transmissão de pacote de dados para o terminal de rádio; c) a determinação do redirecionamento da mensagem NAS inicial para uma rede núcleo correspondendo ao tipo de arquitetura de comunicação determinado; e d) a transmissão para a estação de rádio de uma mensagem de solicitação de mensagem NAS indicando que a mensagem NAS inicial deve ser redirecionada para a rede núcleo correspondente.
[00035] Em um décimo quinto aspecto, um programa inclui um conjunto de instruções (códigos de software) que, quando carregados em um computador, fazem com que o computador realize um método de acordo com o segundo, quarto, sexto, oitavo, décimo, décimo segundo ou décimo quarto aspecto descrito acima.
[00036] De acordo com os aspectos descritos acima, é possível se fornecer um aparelho, um método, e um programa que contribuam para a melhoria da eficiência de um procedimento de comunicação, redução de mensagens de sinalização ou seleção adequada de CN, com relação a um procedimento de comunicação específico envolvendo a determinação (ou seleção) da arquitetura de comunicação utilizada para um UE servindo como um dispositivo CIoT.
[00037] A figura 1 é um diagrama ilustrando um exemplo de arquitetura CIoT:
[00038] A figura 2 é um diagrama ilustrando um exemplo de configuração de uma rede de comunicação de rádio, de acordo com algumas modalidades;
[00039] A figura 3 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação de acordo com uma primeira modalidade;
[00040] A figura 4 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma segunda modalidade;
[00041] A figura 5 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma terceira modalidade;
[00042] A figura 6 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma quarta modalidade;
[00043] A figura 7 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma quinta modalidade;
[00044] A figura 8 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma sexta modalidade;
[00045] A figura 9 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma sétima modalidade;
[00046] A figura 10 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma oitava modalidade;
[00047] A figura 11 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma nona modalidade;
[00048] A figura 12 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma nona modalidade;
[00049] A figura 13 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma décima modalidade;
[00050] A figura 14 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma décima modalidade;
[00051] A figura 15 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma décima primeira modalidade;
[00052] A figura 16 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma décima primeira modalidade;
[00053] A figura 17 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma décima segunda modalidade;
[00054] A figura 18 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma décima terceira modalidade;
[00055] A figura 19 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma décima quarta modalidade;
[00056] A figura 20 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma décima nona modalidade;
[00057] A figura 21 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma décima nona modalidade;
[00058] A figura 22 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma vigésima modalidade;
[00059] A figura 23 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma vigésima modalidade;
[00060] A figura 24 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma vigésima primeira modalidade;
[00061] A figura 25A é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma vigésima primeira modalidade;
[00062] A figura 25B é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com uma vigésima primeira modalidade;
[00063] A figura 26 é um diagrama em bloco ilustrando um exemplo de configuração de um terminal de rádio, de acordo com algumas modalidades;
[00064] A figura 27 é um diagrama em bloco ilustrando um exemplo de configuração de uma estação base de acordo com algumas modalidades; e
[00065] A figura 28 é um diagrama em bloco ilustrando um exemplo de configuração de um nó de rede núcleo, de acordo com algumas modalidades.
[00066] Modalidades específicas são descritas posteriormente em detalhes com referência aos desenhos. Os mesmos elementos ou elementos correspondentes são denotados pelos mesmos símbolos por todos os desenhos, e explicações repetidas são omitidas como necessário para fins de clareza.
[00067] Cada uma das modalidades descritas abaixo pode ser utilizada individualmente, ou duas ou mais das modalidades podem ser adequadamente combinadas uma com a outra. Essas modalidades incluem características de novidade diferentes entre si. De acordo, essas modalidades contribuem para a obtenção dos objetivos ou solução de problemas diferentes um do outro e também contribuem para a obtenção das vantagens diferentes uma da outra.
[00068] As descrições a seguir sobre as modalidades focam basicamente nas redes de comunicação de rádio para CIoT incluindo LTE eMTC e NB-IoT. No entanto, essas modalidades podem ser aplicadas também às redes de comunicação de rádio para outro CIoT.
[00069] A figura 2 ilustra um exemplo de configuração de uma rede de comunicação de rádio de acordo com algumas modalidades incluindo essa modalidade. No exemplo ilustrado na figura 2, um UE 1, que funciona como um dispositivo CIoT, comunica com um servidor de aplicativo 4 através da Rede de Acesso a Rádio (RAN) CIoT 2 e uma Rede Núcleo (CN) 3. A RAN 2 suporta uma pluralidade de tipos de arquiteturas de comunicação para a transmissão de pacote de dados relacionados com CIoT. A RAN 2 difunde, em uma célula, a informação que indica de forma explícita ou implícita a pluralidade de tipos de arquiteturas de comunicação suportados pela RAN 2, pela utilização de um Bloco de Informação Master (MIB) ou um Bloco de informação de Sistema (SIB), por exemplo. O UE 1 suporta pelo menos um desses tipos de arquitetura de comunicação. A CN 3 suporta esses tipos de arquitetura de comunicação. A CN 3 pode incluir CNs dedicadas (DCNs), cada uma associada com um tipo diferente de arquitetura de comunicação.
[00070] Em algumas implementações, a pluralidade de tipos de arquitetura de comunicação pode incluir primeiro e segundo tipos de arquitetura de comunicação correspondentes, respectivamente às soluções 2 e 18, que são descritas na Literatura de Não Patente 1. No primeiro tipo de arquitetura de comunicação, os pacotes de dados de usuário transmitidos ou recebidos pelo UE 1 são transferidos através de um plano de controle (por exemplo, mensagens NAS transmitidas entre o UE e uma MME/C-SGN). No primeiro tipo de arquitetura de comunicação, a RAN 2 não precisa configurar um DRB para transmissão de pacote de dados para o UE 1. Adicionalmente, com referência a SRB utilizado para a transmissão de pacote de dados, a segurança de Extrato de Acesso (AS) (isso é, criptografia e descriptografia dos dados de plano de controle e proteção de integridade e verificação de integridade de dados de plano de controle) pela RAN 2 podem ser omitidos. Em outras palavras, os processos de uma camada de Protocolo de Convergência de Dados em Pacote (PDCP) para SRB utilizados para a transmissão de pacotes de dados podem ser omitidos. Nesse caso, os pacotes de dados para o UE 1 são criptografados e descriptografados pelo UE 1 e CN 3 (por exemplo, MME ou C-SGN) pela utilização de chaves de segurança NAS. Em contraste com isso, no segundo tipo de arquitetura de comunicação, os pacotes de dados de usuário transmitidos ou recebidos pelo UE 1 são transferidos através de um plano de usuário (por exemplo, um suporte EPS incluindo um DRB e um túnel de Protocolo de Canalização (GTP) do Serviço de Rádio em Pacote Geral (GPRS).
[00071] O UE 1 pode suportar um ou ambos LTE eMTC e NB-IoT. Em outras palavras, o UE 1 pode suportar um ou ambos dentre RAT CIoT (RAT NB-IoT) e RAT LTE (eMTC). A RAN 2 pode incluir um ou ambos um ou ambos dentre BS CIoT suportando RAT CIoT (RAT NB- IoT) e um eNB suportando RAT LTE (eMTC). A CN 3 pode incluir um C-SGN, ou uma MME e um S-GW, ou ambos. Adicionalmente, a CN 3 pode incluir outras entidades de rede tal como P-GW, um Servidor de Assinante Doméstico (HSS), e uma Função de Política e Regras de Cobrança (PCRF).
[00072] A figura 3 é um diagrama em sequência ilustrando um exemplo de um procedimento de comunicação de acordo com essa modalidade. No procedimento ilustrado na figura 3, um tipo de arquitetura de comunicação a ser utilizado para a transmissão de pacote de dados para o UE 1 é determinado durante um procedimento para a fixação do UE 1 à CN 3. O UE 1 determina um tipo de arquitetura de comunicação a ser utilizado para a transmissão de pacotes de dados para o UE 1 e transmite para a RAN 2 uma mensagem de Solicitação de Conexão RRC incluindo uma causa de estabelecimento indicando de forma explícita ou implícita o tipo de arquitetura de comunicação determinado.
[00073] Na etapa 301, o UE 1 determina (ou seleciona) um tipo de arquitetura de comunicação a ser utilizado para a transmissão de pacote de dados para o UE 1. Em algumas implementações, o UE 1 pode selecionar um tipo de arquitetura de comunicação a ser utilizado com base em uma capacidade padrão de UE que foi pré-configurado no UE 1. Adicionalmente ou alternativamente, o UE 1 pode medir a potência recebida do sinal de referência (RSRP) da RAN 2 ou uma perda de propagação estimada entre o UE 1 e a RAN 2 (CIoT- BS/eNB) e selecionar um tipo de arquitetura de comunicação a ser utilizado com base no RSRP medido ou perda de propagação. Adicio-nalmente ou alternativamente, o UE 1 pode determinar um nível de melhoria de cobertura necessário (CE) com base no RSRP medido ou perda de propagação e selecionar um tipo de arquitetura de comunicação com base no nível CE determinado. Adicionalmente ou alternativamente, o UE 1 pode selecionar um tipo de arquitetura de comunicação de acordo com um acionador de transmissão de dados (por exemplo, mo-Data, mo-ExceptionData, mt-Access, ou mo-Signaling). Adicionalmente ou alternativamente, o UE 1 pode selecionar um tipo de arquitetura de comunicação de acordo com o tipo de um aplicativo que realiza a transmissão de pacote de dados.
[00074] Na etapa 302, o UE 1 inicia um procedimento de acesso randômico. Isso é, o UE 1 transmite um preâmbulo de acesso randô- mico (isso é, um preâmbulo de Canal de Acesso Randômico (RACH)) para a RAN 2 e recebe uma mensagem de resposta de acesso ran- dômico (RAR) da RAN 2.
[00075] Na etapa 303, o UE 1 transmite uma terceira mensagem (Msg3) no procedimento de acesso randômico (isso é, uma mensagem de Solicitação de Conexão RRC) para a RAN 2. Essa mensagem de Solicitação de Conexão RRC é transmitida por um SRB 0 em um Canal de Controle Comum (CCCH). A mensagem de Solicitação de Conexão RRC inclui uma elemento de informação de causa de estabelecimento indicando de forma explícita ou implícita um tipo de arquitetura de comunicação determinado (ou selecionado) pelo UE 1.
[00076] Com referência à causa do estabelecimento indicando o tipo de arquitetura de comunicação, por exemplo, uma das causas normais de estabelecimento (por exemplo, mo-Data, mo-ExceptionData, mo-Signaling, mt-Access) pode ser utilizada para indicar o primeiro (ou segundo) tipo de arquitetura de comunicação e uma causa de estabelecimento específica pode ser utilizada para indicar o segundo (ou primeiro) tipo de arquitetura de comunicação. Quando uma causa específica de estabelecimento é utilizada para o primeiro tipo de arquitetura de comunicação, a mesma pode, por exemplo, ser informação (por exemplo, mo-DataOverNAS, mo-ExceptionDataOverNAS, mo- SignalingDataOverNAS, ou Mt-AccessDataOverNAS) indicando um tipo de arquitetura de comunicação no qual os dados de usuário são transmitidos por uma mensagem NAS. Quando uma causa específica de estabelecimento é utilizada para o segundo tipo de arquitetura de comunicação, a mesma pode ser, por exemplo, informação (por exemplo, mo-DataUP, Mo-ExceptionDataUP, Mo-SignalingUP ou Mt- AccessUP) indicando que um DRB é configurado e que dados de usu- ário são transmitidos através de um Plano de Usuário (UP) (uma mensagem AS).
[00077] Na etapa 304, depois de receber a mensagem de Solicitação de Conexão RRC, a RAN 2 transmite uma mensagem de Configuração de Conexão RRC para o UE 1. Essa mensagem de Configuração de Conexão RRC é transmitida por um SRB 0 em um CCCH. A mensagem de Configuração de Conexão RRC inclui a informação de configuração referente a um SRB 1 e permite que a sinalização subsequente utilize um Canal de Controle Dedicado (DCCH).
[00078] A mensagem de Configuração de Conexão RRC pode indicar uma necessidade por um PDCP. Mais especificamente, a mensagem de Configuração de Conexão RRC pode indicar a necessidade de se criar um PDCP (por exemplo, se um PDCP for utilizado de forma similar à forma convencional) para o UE 1. Em algumas implementações, a informação de indicador que indica a necessidade de um PDCP, podem ser incluídas em um IE RadioResourceConfigDedicated ou outro IE incluído na mensagem de Configuração de Conexão RRC.
[00079] Em algumas implementações, uma configuração PDCP (pdcp-config) incluída na mensagem de Configuração de Conexão RRC pode indicar a necessidade de um PDCP. Essa configuração PDCP pode incluir informação de indicador indicando a necessidade de um PDCP (por exemplo, se um PDCP for utilizado de forma similar à forma convencional) para o UE 1. A configuração PDCP pode incluir informação indicando se uma configuração padrão de PDCP Config de SRB 1 deve estar ativada para UE 1. A configuração PDCP pode incluir um PDCP Config específico (por exemplo, comprimento de Número de Sequência (SN) PDCP e RLC-SAP aplicado a SRB 1). Alternativamente, a RAN 2 pode determinar se inclui a configuração PDCP (pdcp- Config) na mensagem de Configuração de Conexão RRC dependendo do tipo de arquitetura de comunicação determinado pelo UE 1. Especi- ficamente, se o UE 1 selecionar o segundo tipo de arquitetura de co-municação, a RAN 2 pode incorporar a configuração PDCP para SRB 1 na mensagem de Configuração de Conexão RRC.
[00080] Na etapa 305, o UE 1 transmite uma mensagem de Configuração de Conexão RRC Completada para a RAN 2. Essa mensagem de Configuração de Conexão RRC Completada é transmitida por um SRB 1 em um DCCH. A mensagem de Configuração de Conexão RRC Completada porta uma mensagem NAS inicial. Note-se que visto que a figura 3 ilustra o procedimento de anexação, a mensagem NAS inicial é uma mensagem de Solicitação de Anexação. Essa mensagem de Solicitação de Anexação inclui um Elemento de Informação (IE) de tipo de anexação EPS configurado para "CIoT Attach".
[00081] A RAN 2 recebe a mensagem de Configuração de Conexão RRC Completada do UE 1 e envia a mensagem NAS inicial (isso é, a mensagem de Solicitação de Anexação) recuperada da mensagem de Configuração de Conexão RRC Completada para a CN 3 (por exemplo, MME ou C-SGN) utilizando um S1AP: mensagem UE inicial. A mensagem NAS inicial (isso é, mensagem de Solicitação de Anexação) é embutida em um Elemento de Informação (IE) da Unidade de Dados de Protocolo-NAS (PDU) de S1AP: Mensagem UE inicial. A RAN 2 pode incorporar um elemento de informação indicando o tipo de arquitetura de comunicação determinado (ou selecionado) pelo UE 1 em S1AP; Mensagem UE inicial. A RAN 2 pode selecionar, a partir de DCNs na CN 3, uma DCN correspondente ao tipo de arquitetura de comunicação determinado pelo UE 1 e envia S1AP: mensagem UE inicial portando a mensagem NAS inicial (isso é, a mensagem de Solicitação de Anexação) para a DCN selecionada.
[00082] Na etapa 306, a CN 3 (por exemplo, MME ou C-SGN) realiza um procedimento de autenticação e segurança e, dessa forma, configura a segurança NAS. Uma mensagem NAS de downlink necessária para o procedimento de autenticação e segurança (isso é, uma Solicitação de Autenticação e um Comando de Modo de Segurança NAS) é transmitida por um mensagem de Transferência de Informação RRC:DL em SRB 1. De forma similar, uma mensagem NAS de uplink necessária para o procedimento de autenticação e segurança (isso é, uma Resposta de Autenticação e um Modo de Segurança NAS Completo) é transmitida por um mensagem de Transferência de Informação RRC:UL no SRB 1.
[00083] Na etapa 307, a CN 3 (por exemplo, MME ou C-SGN) envia uma mensagem de NAS:Anexo Aceito para o UE 1. A configuração de uma sessão para o UE 1 (por exemplo, um DRB e um suporte S1) não é necessária. De acordo, CN 3 (por exemplo, MME ou C-SGN) não precisa enviar uma mensagem S1AP: Solicitação de Configuração de Contexto Inicial para a RAN 2 (por exemplo, CIoT-BS ou eNB). Dessa forma, a mensagem de Aceitação de Anexação pode ser transmitida da CN 3 para a RAN 2 por uma mensagem de transporte S1AP:NAS em downlink. A RAN 2 transmite a mensagem de Aceitação de Anexação para o UE 1 em SRB 1 utilizando uma mensagem de RRC: Transferência de Informação DL.
[00084] O UE 1 recebe a mensagem de Aceitação de Anexação a partir da CN 3 através da RAN 2. A mensagem de Aceitação de Anexação pode indicar um tipo de dados de transferência (por exemplo, IP, não IP ou SMS) e um endereço UE (por exemplo, endereço IP). Depois do recebimento da mensagem de Aceitação de Anexação, o UE 1 transmite uma mensagem NAS:Anexação Completada para CN 3. Essa mensagem de Anexação Completada é transmitida para a RAN 2 por uma mensagem RRC:Transferência de Informação UL no SRB 1. A RAN 2 envia a mensagem de Anexação Completada recebida para a CN 3 utilizando uma mensagem S1AP:Transporte NAS em uplink.
[00085] Na etapa 308, a RAN 2 transmite uma mensagem de Liberação de Conexão RRC para o UE 1 no SRB 1. A CN 3 pode solicitar a RAN 2 que libere a conexão RRC com o UE 1 pelo envio de uma mensagem S1AP: Comando de Liberação de Contexto UE S1 para a RAN 2. Depois do recebimento da mensagem de Liberação de Conexão RRC, o UE 1 transita do modo RRC Conectado para o modo RRC Inativo. Para o UE 1 servindo como um dispositivo CIoT, outro modo de suspensão ou estado diferente do modo RRC inativo pode ser definido. Dessa forma, depois do recebimento da mensagem de Liberação de Conexão RRC, o UE 1 pode entrar no modo RRC Inativo ou outro modo de suspensão. O outro modo ou estado de suspensão pode ser utilizado no segundo tipo de arquitetura de comunicação a fim de reter informação sobre a conexão RRC (por exemplo, um Contexto de Segurança de Extrato de Acesso, informação relacionada com suporte e parâmetros L2/1).
[00086] A mensagem de Aceitação de Anexação na etapa 307, a mensagem de Liberação de Conexão RRC na etapa 308, ou outra mensagem NAS de downlink transmitida a partir da CN 3 para o UE 1 podem indicar de forma explícita ou implícita um tipo de arquitetura de comunicação a ser utilizado para o UE 1 (por exemplo, um Tipo de Arquitetura Aplicada ou um Tipo de Arquitetura Selecionado).
[00087] Na etapa 309, o UE 1 registra (armazena) o tipo de arquitetura de comunicação configurado durante o procedimento de anexação.
[00088] O procedimento ilustrado na figura 3 pode ser modificado como segue. O UE 1 pode incluir, em adição à causa normal do estabelecimento, outro elemento de informação na mensagem de Solicitação de Conexão RRC (etapa 303) para indicar o tipo de arquitetura de comunicação. Esse elemento de informação pode ser, por exemplo, um elemento de informação indicando qual dentre o primeiro e segun do tipos de arquitetura de comunicação o UE 1 selecionou (por exemplo, um Tipo de Arquitetura Selecionado ou um Tipo de Arquitetura Aplicado). Por exemplo, o UE 1 pode configurar o valor do elemento de informação para "DataOverNAS (DONAS)" ou "Tipo 1" a fim de indicar o primeiro tipo de arquitetura de comunicação, e configurar o valor do elemento de informação para "RRC-Suspenso" ou "Tipo 2" a fim de indicar o segundo tipo de arquitetura de comunicação.
[00089] Por exemplo, o elemento de informação descrito acima pode ser definido como "SelectedArcType ENUMERATED {type1, type2} (ou, {DataOverNAS, RRC-Suspended})". Alternativamente, o elemento de informação pode ser informação de indicador indicando que o primeiro tipo de arquitetura de comunicação foi selecionado (por exemplo, SelectedArcType ENUMERATED {type1}, ou ArcType1 ENUMERATED {true}). Alternativamente, o elemento de informação pode ser a informação de indicador indicando que o segundo tipo de arquitetura de comunicação foi selecionado (por exemplo, SelectedArcType ENUMERATED {type2}, ou ArcType2 ENUMERATED {true}).
[00090] Se o UE 1 implementar um método de transmissão de informação de indicador indicando que um dentre os dois tipos de arquitetura de comunicação (por exemplo, o segundo tipo de arquitetura de comunicação) foi selecionado, o uso de outro tipo de arquitetura de comunicação (por exemplo, o primeiro tipo de arquitetura de comunicação) pelo UE 1 pode ser definido como uma configuração padrão (ou uma configuração básica). Dessa forma, quando o UE 1 não transmitir a informação de indicador, o mesmo indica implicitamente que o UE 1 selecionou o tipo de arquitetura de comunicação padrão. Isso é, se a RAN 2 não receber a informação de indicador, a RAN 2 reconhece que o UE 1 selecionou o tipo de arquitetura de comunicação padrão.
[00091] O procedimento ilustrado na figura 3 pode ser adicional- mente modificado como segue. A RAN 2 pode utilizar um tipo de arquitetura de comunicação diferente do tipo de arquitetura de comunicação indicado pelo UE 1 na mensagem de Solicitação de Conexão RRC (etapa 303). Nesse caso, a RAN 2 pode notificar o UE 1 sobre esse tipo de arquitetura de comunicação diferente (por exemplo, um Tipo de Arquitetura Aplicado ou um Tipo de Arquitetura Selecionado) utilizando a mensagem de Configuração de Conexão RRC (etapa 304). Alternativamente, a RAN 2 pode transmitir para o UE 1 na etapa 304 uma mensagem de Rejeição de Conexão RRC, em vez da mensagem de Configuração de Conexão RRC, e notificar o UE 1 sobre o tipo diferente de arquitetura de comunicação utilizando essa mensagem. Depois de receber a notificação sobre o tipo diferente de arquitetura de comunicação, o UE 1 pode encerrar o procedimento de anexação atual e reiniciar um novo procedimento de configuração de conexão RRC. Alternativamente, o UE 1 pode continuar com o procedimento de anexação atual e o procedimento de configuração de conexão RRC, de acordo com a notificação do tipo diferente de arquitetura de comunicação transmitido a partir da RAN 2.
[00092] Quando o segundo tipo de arquitetura de comunicação, no qual os pacotes de dados de usuário são transmitidos através do plano de usuário (por exemplo, um suporte EPS incluindo um DRB e um túnel do Protocolo de Canalização GPRS (GTP)), é utilizado para UE 1, a CN 3 pode incorporar a mensagem NAS:Aceitação de Anexação em uma mensagem S1AP: Solicitação de Configuração de Contexto Inicial e transmite as mesmas para a RAN 2 na etapa 307. Essa mensagem S1AP: Solicitação de Configuração de Contexto Inicial inclui uma chave de segurança (KeNB)e um Algoritmo de Segurança UE utilizado para o UE 1. A RAN 2 pode realizar uma configuração de segurança AS de acordo com a chave de segurança recebida (KeNB) e Algoritmo de Segurança UE. A configuração de segurança AS pode ser realizada an tes ou depois da transmissão da mensagem NAS:Aceitação de Anexação para o UE 1.
[00093] Apesar de a figura 3 ilustrar a transmissão de dados Originadas em Móvel (MO), um procedimento similar ao ilustrado na figura 3 pode ser aplicado à transmissão de dados Encerrada em Móvel (MT).
[00094] No exemplo ilustrado na figura 3, o UE 1 determina um tipo de arquitetura de comunicação a ser utilizado para a transmissão de pacote de dados para o UE 1 e transmite para a RAN 2 uma mensagem de Solicitação de Conexão RRC incluindo uma causa de estabelecimento ou outro elemento de informação indicando o tipo de arquitetura de comunicação determinado. Utilizando-se a causa de estabelecimento ou outro elemento de informação incluído na mensagem de Solicitação de Conexão RRC para indicar o tipo de arquitetura de comunicação determinado pelo UE 1 fornece as seguintes vantagens, por exemplo. Em primeiro lugar, permite que o UE 1 transmita um tipo de arquitetura de comunicação determinado pelo UE 1 como informação AS (RRC), em vez de como informação NAS. Portanto, a RAN 2 pode reconhecer o tipo de arquitetura de comunicação desejado pelo UE 1 e, dessa forma, a RAN 2 pode realizar o processo (por exemplo, seleção de uma CN (DCN)) de acordo com o tipo de arquitetura de comunicação desejado pelo UE 1. Em segundo lugar, permite que o UE 1 notifique a RAN 2 sobre o tipo de arquitetura de comunicação determinado pelo UE 1, antes do estabelecimento de uma conexão RRC. Dessa forma, a RAN 2 pode reduzir o número de mensagens de sinalização necessário parar se configurar uma conexão RRC de acordo com o tipo de arquitetura de comunicação determinado pelo UE 1.
[00095] Um exemplo de configuração de uma rede de comunicação de rádio de acordo com essa modalidade é similar a um ilustrado na figura 2. Essa modalidade fornece outro procedimento de comunicação envolvendo a determinação (ou seleção) da arquitetura de comunicação utilizada para o UE 1. A figura 4 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação de acordo com essa modalidade. No procedimento ilustrado na figura 4, um tipo de arquitetura de comunicação a ser utilizado para a transmissão de pacote de dados para o UE 1 é determinado durante um procedimento de anexação do UE 1 à CN 3. O UE 1 determina um tipo de arquitetura de comunicação a ser utilizado para a transmissão de pacote de dados para o UE 1 e transmite para a RAN 2 uma mensagem de Configuração de Conexão RRC Completada incluindo um elemento de informação sobre o tipo de arquitetura de comunicação determinado, que indica de forma explícita ou implícita o tipo de arquitetura de comunicação determinado.
[00096] As etapas 401 a 404 são etapas similares às etapas 301 a 304 ilustradas na figura 3. No entanto, uma mensagem de Solicitação de Conexão RRC na etapa 403 não indica o tipo de arquitetura de comunicação determinado (selecionado) pelo UE 1.
[00097] Na etapa 405, o UE 1 transmite uma mensagem de Configuração de Conexão RRC Completada para a RAN 2. Essa mensagem de Configuração de Conexão RRC Completada é transmitida por um SRB 1 em um DCCH. A mensagem de Configuração de Conexão RRC Completada inclui uma mensagem NAS inicial e um Elemento de Informação de assistência UE (IE) sobre o tipo de arquitetura de comunicação determinado pelo UE 1, que indica de forma explícita ou implícita o tipo de arquitetura de comunicação. O IE de assistência UE pode ser informação NAS ou pode ser informação AS (RRC).
[00098] Quando IE de assistência UE é informação AS (RRC), dependendo do tipo de arquitetura de comunicação determinado pelo UE 1, a RAN 2 pode transmitir uma configuração PDCP (pdcp-Config) para SRRB 1 para o UE 1 ou pode notificar o UE 1 que uma camada PDCP é utilizada (aplicada). Especificamente, a RAN 2 pode transmitir a configuração PDCP para SRB 1 para o UE 1 quando o UE 1 selecionar o segundo tipo de arquitetura de comunicação.
[00099] A RAN 2 recebe a mensagem de Configuração de Conexão RRC Completada do UE 1 e envia para a CN 3 uma mensagem NAS inicial (isso é, uma mensagem de Solicitação de Anexação) recuperada da mensagem de Configuração de Conexão RRC Completada (por exemplo, MME ou C-SGN), utilizando uma mensagem UE inicial. Quando o IE de assistência UE e a informação AS (RRC), a RAN 2 pode selecionar, a partir das DCNs na CN 3, uma DCN correspondente ao tipo de arquitetura de comunicação determinado pelo UE 1 e enviar a mensagem UE inicial portando a mensagem NAS inicial (isso é, a mensagem de Solicitação de Anexação) para a DCN selecionada. Em contraste com isso, quando o IE de assistência UE é informação NAS, o IE de assistência UE é incorporado a um Elemento de Informação NAS-PDU (IE) da mensagem S1AP:UE Inicial juntamente com a mensagem NAS inicial. Nesse caso, a RAN 2 pode receber uma notificação indicando de forma explícita ou implícita o tipo de arquitetura de comunicação determinado pelo UE 1 a partir da CN 3 utilizando, por exemplo, uma mensagem de Solicitação de Configuração de Contexto Inicial (por exemplo, um IE de Tipo de Arquitetura).
[000100] As etapas 406 a 409 são similares às etapas 306 a 309 ilustradas na figura 3.
[000101] O procedimento ilustrado na figura 4 pode ser modificado, por exemplo, como segue. A RAN 2 ou a CN 3 pode utilizar um tipo de arquitetura de comunicação diferente do tipo de arquitetura de comunicação indicado pelo UE 1 na mensagem de Configuração de Conexão RRC Completada ou mensagem de Solicitação de Anexação do UE 1 (etapa 404).
[000102] Em resposta à mensagem de Configuração de Conexão RRC Completada (etapa 404), a RAN 2 pode transmitir uma mensagem de Rejeição de Conexão RRC indicando o tipo de arquitetura de comunicação diferente (por exemplo, um Tipo de Arquitetura Aplicada ou um Tipo de Arquitetura Selecionada) para o UE 1. Nesse caso, o UE 1 pode reiniciar um novo procedimento de Configuração de Conexão RRC.
[000103] Alternativamente a CN 3 pode notificar o UE 1 sobre o tipo diferente de arquitetura de comunicação (por exemplo, um Tipo de Arquitetura Aplicada ou um Tipo de Arquitetura Selecionada) utilizando a mensagem de Aceitação de Anexação (etapa 407). Nesse caso, o UE 1 pode encerrar o procedimento de anexação atual e reiniciar um novo procedimento de configuração de conexão RRC. Alternativamente, o UE 1 pode continuar com o procedimento de anexação atual de acordo com a notificação do tipo diferente de arquitetura de comunicação transmitido a partir da RAN 2.
[000104] Quando o segundo tipo de arquitetura de comunicação, no qual pacotes de dados de usuário são transmitidos através do plano de usuário (por exemplo, um suporte EPS incluindo um DRB e um túnel do Protocolo de Canalização GPRS (GTP) é utilizado para o UE 1, a CN 3 pode incorporar a mensagem NAS:Aceitação de Anexação em uma mensagem S1AP: Solicitação de Configuração de Contexto Inicial e transmitir as mesmas para RAN 2 na etapa 407. Essa mensagem S1AP: Solicitação de Configuração de Contexto Inicial inclui uma chave de segurança (KeNB) e um Algoritmo de Segurança UE utilizado para UE 1. A RAN 2 pode realizar uma configuração de segurança AS de acordo com a chave de segurança recebida (KeNB) e o Algoritmo de Segurança UE. A configuração de segurança AS pode ser realizada antes ou depois da transmissão da mensagem NAS:Aceitação de Anexação para o UE 1.
[000105] Apesar de a figura 4 ilustrar a transmissão de dados Originada de Móvel (MO), um procedimento similar ao ilustrado na figura 4 pode ser aplicado à transmissão de dados Encerrados em Móvel (MT).
[000106] No exemplo ilustrado na figura 4, o UE 1 determina um tipo de arquitetura de comunicação a ser utilizado para a transmissão de pacote de dados para o UE 1 e transmitir para a RAN 2 uma mensagem de Configuração de Conexão RRC Completada incluindo um IE de assistência UE indicando o tipo de arquitetura de comunicação determinado. Utilizando-se a mensagem de Configuração de Conexão RRC Completada para indicar o tipo de arquitetura de comunicação determinado pelo UE 1 fornece as seguintes vantagens, por exemplo. Em algumas implementações, permite que o UE 1 transmita um tipo de arquitetura de comunicação determinado pelo UE 1 como informação NAS. Portanto, o UE 1 pode notificar com facilidade a CN 3 sobre o tipo de arquitetura de comunicação desejado pelo UE 1.
[000107] Um exemplo de configuração de uma rede de comunicação de rádio de acordo com essa modalidade é similar a um ilustrado na figura 2. Essa modalidade fornece outro procedimento de comunicação envolvendo a determinação (ou seleção) da arquitetura de comunicação utilizada para o UE 1. A figura 5 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação de acordo com essa modalidade. No procedimento ilustrado na figura 5, a RAN 2 determina (ou seleciona) um tipo de arquitetura de comunicação a ser utilizado para a transmissão de pacote de dados para o UE 1, durante um procedimento para fixação do UE 1 à CN 3.
[000108] As etapas 501 a 504 são similares às etapas 402 e 405 ilustradas na figura 4. No entanto, uma mensagem de Configuração de Conexão RRC Completada na etapa 504 inclui um elemento de infor- mação sobre os tipos de arquitetura de comunicação (por exemplo, um Tipo de Arquitetura Suportado por UE), que indica de forma explícita ou implícita um ou mais tipos de arquitetura de comunicação suportados pelo UE 1. Esse elemento de informação é a informação AS (RRC). De acordo, esse elemento de informação permite que a RAN 2 (por exemplo, CIoT-BS ou eNB) detecte um ou mais tipos de arquitetura de comunicação suportados pelo UE 1.
[000109] Esse elemento de informação pode indicar, por exemplo, os tipos de arquitetura de comunicação suportados pelo UE 1 (por exemplo, {type1, type2,...}, ou {DONAS, RRC-suspenso,...}). O elemento de informação pode ser um mapa de bit indicando quais dentre uma pluralidade de tipos de arquitetura de comunicação são suportados pelo UE 1. O elemento de informação pode ser um indicador ou um mapa de bit indicando se um ou mais tipos de arquitetura de comunicação opcionais além de um tipo de arquitetura de comunicação padrão são suportados pelo UE 1. O elemento de informação pode ser um indicador ou um mapa de bits indicando se um ou mais tipos de arquitetura de comunicação opcional além de um tipo de arquitetura de comunicação padrão são suportados pelo UE 1. Isso é, o elemento de informa-ção pode indicar que um tipo de arquitetura de comunicação opcional é suportado (por exemplo, Suporte typeX = ENUMERATED {verdadeiro,...}, ou {Suportado, Não Suportado}). Os valores descritos acima "type1" e "type2" (e "typeX") podem ser substituídos por nomes que indicam um tipo de arquitetura de comunicação de uma forma mais específica, tal como "DataOverNAS(DONAS)" ou "RRC-Suspenso".
[000110] Na etapa 505, a RAN 2 determina um tipo de arquitetura de comunicação a ser utilizado para UE 1 enquanto considerada um ou mais tipos de arquitetura de comunicação suportados pelo UE 1. Em algumas implementações, a RAN 2 pode selecionar um tipo de arquitetura de comunicação utilizado para o UE 1 com base em uma capa- cidade UE padrão que foi pré-configurada no UE 1. Adicionalmente, ou alternativamente, a RAN 2 pode selecionar um tipo de arquitetura de comunicação utilizado para UE 1 com base na potência recebida no UE 1 de um sinal de referência transmitido a partir da RAN 2 (isso é, RSRP) ou uma perda de propagação estimada entre o UE 1 e a RAN 2 (por exemplo, CIoT-BS/eNB). Um resultado da medição de RSRP ou perda de propagação pode ser enviado do UE 1 para a RAN 2. Adicionalmente ou alternativamente, a RAN 2 pode selecionar um tipo de arquitetura de comunicação utilizado para o UE 1 com base em uma capacidade de rede da CN 3. Adicionalmente ou alternativamente, a RAN 2 pode selecionar um tipo de arquitetura de comunicação utilizado para UE 1 com base em uma carga na RAN 2 (por exemplo, uma carga de célula, uma carga de Camada de Rede de Transporte S1 (TNL), o número de UEs Conectados ou o número de UEs cujo contexto UE está armazenado).
[000111] Dependendo do tipo de arquitetura de comunicação determinado pelo UE 1, a RAN 2 pode transmitir uma configuração PDCP (pdcp-Config) para SRB 1 para o UE 1 ou pode notificar o UE 1 que uma camada PDCP é utilizada (aplicada). Especificamente, a RAN 2 pode transmitir a configuração PDCP para SRB 1 para o UE 1 quando a RAN 2 seleciona o segundo tipo de arquitetura de comunicação para UE 1.
[000112] Na etapa 506, a RAN 2 envia uma mensagem NAS inicial (isso é, a mensagem de Solicitação de Anexação) recuperada da mensagem de Configuração de Conexão RRC Completada para a CN 3 (por exemplo, MME ou C-SGN) utilizando uma mensagem S1AP:UE Inicial. A mensagem NAS inicial (isso é, mensagem de Solicitação de Anexação) é embutida em um Elemento de Informação NAS-PDU (IE) da mensagem S1AP:UE Inicial. A RAN 2 pode incorporar um elemento de informação indicando o tipo de arquitetura de comunicação deter- minado na etapa 505 na mensagem S1AP:mensagem UE Inicial. A RAN 2 pode selecionar, a partir de DCNs na CN 3, uma DCN correspondente ao tipo de arquitetura de comunicação determinado na etapa 505 e enviar a mensagem S1AP:mensagem UE Inicial portando a mensagem NAS inicial (isso é, mensagem de Solicitação de Anexação) para DCN selecionada.
[000113] As etapas 507 a 510 são similares às etapas 306 a 309 na figura 3 ou etapas 406 a 409 na figura 4.
[000114] Quando o segundo tipo de arquitetura de comunicação é utilizado para UE 1, o procedimento ilustrado na figura 5 pode ser alterado de modo que uma configuração de segurança AS seja realizada como no caso dos outros procedimentos descritos acima. Apesar de a figura 5 ilustrar a transmissão de dados Originada em Móvel (MO), um procedimento similar ao ilustrado na figura 5 pode ser aplicado à transmissão de dados Encerrada em Móvel (MT).
[000115] Um exemplo de configuração de uma rede de comunicação de rádio de acordo com essa modalidade é similar a um ilustrado na figura 2. Essa modalidade fornece outro procedimento de comunicação envolvendo a determinação (ou seleção) da arquitetura de comunicação utilizada para o UE 1. A figura 6 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação de acordo com essa modalidade. No procedimento ilustrado na figura 6, a RAN 2 determina um tipo de arquitetura de comunicação utilizado para a transmissão de pacotes de dados para o UE 1, durante um procedimento para a fixação do UE 1 à CN 3. Note-se que o procedimento ilustrado na figura 6 difere do ilustrado na figura 5 visto que um elemento de informação sobre os tipos de arquitetura de comunicação (por exemplo, um Tipo de Arquitetura Suportada por UE), que indica de forma explícita ou implícita um ou mais tipos de arquitetura de co- municação suportados pelo UE 1, é transmitido por uma mensagem de Solicitação de Conexão RRC.
[000116] As etapas 601 e 602 são similares às etapas 302 e 303 ilustradas na figura 3. No entanto, uma mensagem de Solicitação de Conexão RRC na etapa 602 inclui um elemento de informação indicando um ou mais tipos de arquitetura de comunicação suportados pelo UE 1 (por exemplo, um Tipo de Arquitetura Suportado por UE). Esse elemento de informação é a informação AS (RRC). De acordo, esse elemento de informação permite que a RAN 2 (por exemplo, CIoT-BS ou eNB) para detectar um ou mais tipos de arquitetura de comunicação suportados pelo UE 1.
[000117] Na etapa 603, a RAN 2 determina um tipo de arquitetura de comunicação utilizado para o UE 1 enquanto considera um ou mais tipos de arquitetura de comunicação suportados pelo UE 1.
[000118] A etapa 604 é similar à etapa 304 na figura 3. No entanto, uma mensagem de Configuração de Conexão RRC na etapa 604 pode indicar o tipo de arquitetura de comunicação determinado pela RAN 2 na etapa 603 (por exemplo, um Tipo de Arquitetura Aplicada ou um Tipo de Arquitetura Selecionada).
[000119] As etapas 605 e 606 são similares às etapas 305 na figura 3. No entanto, a RAN 2 pode incorporar um elemento de informação indicando o tipo de arquitetura de comunicação determinado na etapa 603 (por exemplo, um Tipo de Arquitetura Aplicada ou um Tipo de Arquitetura Selecionada) na mensagem S1AP:UE Inicial. A RAN 2 pode selecionar, a partir das DCNs na CN 3, uma DCN correspondendo ao tipo de arquitetura de comunicação determinado na etapa 603 e enviar a mensagem S1AP:UE Inicial portando a mensagem NAS inicial (isso é, a mensagem de Solicitação de Anexação) para a DCN selecionada.
[000120] As etapas 607 a 610 são similares às etapas 306 a 3099 na figura 3 ou etapas 507 a 510 na figura 5.
[000121] Quando o segundo tipo de arquitetura de comunicação é utilizado para UE 1, o procedimento ilustrado na figura 6 pode ser alterado de modo que uma configuração de segurança AS seja realizada como no caso dos outros procedimentos descritos acima. Apesar de a figura 6 ilustrar a transmissão de dados Originados em Móvel (MO), um procedimento similar ao ilustrado na figura 6 pode ser aplicado à transmissão de dados Encerrada em Móvel (MT).
[000122] Um exemplo de configuração de uma rede de comunicação de rádio de acordo com essa modalidade é similar ao ilustrado na figura 2. Essa modalidade fornece outro procedimento de comunicação envolvendo a determinação (ou seleção) da arquitetura de comunicação utilizada para o UE 1. A figura 7 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação de acordo com essa modalidade. No procedimento ilustrado na figura 7, a RAN 2 determina um tipo de arquitetura de comunicação utilizado para a transmissão de pacotes de dados para o UE 1, durante um procedimento de anexação do UE 1 à CN 3. Note-se que o procedimento ilustrado na figura 7 difere dos ilustrados nas figuras 5 e 6 visto que um elemento de informação sobre os tipos de arquitetura de comunicação suportados pelo UE 1 (por exemplo, um Tipo de Arquitetura Suportado por UE), que indica explicitamente ou implicitamente um ou mais tipos de arquitetura de comunicação suportados pelo UE 1, é transmitido como informação NAS juntamente com uma mensagem NAS inicial (isso é, uma mensagem de Solicitação de Anexação).
[000123] As etapas 701 a 704 são similares às etapas 402 a 405 ilustradas na figura 4. No entanto, na etapa 704, o UE 1 transmite um elemento de informação NAS indicando um ou mais tipos de arquitetura de comunicação suportados pelo UE 1 (por exemplo, um Tipo de Arquitetura Suportado por UE) juntamente com a mensagem de Solici- tação de Anexação. Esse elemento de informação NAS pode indicar, por exemplo, um tipo de arquitetura de comunicação suportado pelo UE 1 (por exemplo, {type1, type2,...}, ou {DONAS, RRC-Suspenso,...}). Alternativamente, o elemento de informação NAS pode indicar que um tipo de arquitetura de comunicação opcional é suportado (por exemplo, TypeX suportado), ou pode indicar se o tipo de arquitetura de comunicação opcional é suportado (por exemplo, Suporte de typeX = ENUMERATED {verdadeiro,...}, ou {Suportado, Não Suportado}). Os valores descritos acima "type1" e "type2" (e "typeX") podem ser substituídos por nomes que indicam um tipo de arquitetura de comunicação de uma forma mais específica, tal como "DataOverNAS (DONAS)" ou "RRC-Suspenso".
[000124] Na etapa 705, a CN 3 envia uma mensagem S1AP: Solicitação de Configuração de Contexto Inicial indicando um ou mais tipos de arquitetura de comunicação suportados pelo UE 1 (por exemplo, o Tipo de Arquitetura Suportado por UE) para a RAN 2. Na etapa 706, a RAN 2 determina um tipo de arquitetura de comunicação utilizado para UE 1 enquanto considera os um ou mais tipos de arquitetura de comunicação suportados pelo UE 1 com base na informação recebida da CN 3. A RAN 2 pode notificar à CN 3 sobre o tipo de arquitetura de comunicação determinado utilizando uma mensagem S1AP:Resposta de Configuração de Contexto Inicial (etapa 707).
[000125] As etapas 708 a 711 são similares às etapas 306 a 309 na figura 3, etapas 507 a 510 na figura 5, ou etapas 607 a 610 na figura 6.
[000126] Quando o segundo tipo de arquitetura de comunicação é utilizado para o UE 1, o procedimento ilustrado na figura 7 pode ser alterado de modo que uma configuração de segurança AS seja realizada como no caso dos outros procedimentos descritos acima. Apesar de a figura 7 ilustrar a transmissão de dados Originados em Móvel (MO), um procedimento similar ao ilustrado na figura 7 pode ser apli- cado à transmissão de dados Encerrada em Móvel (MT).
[000127] Um exemplo de configuração de uma rede de comunicação de rádio de acordo com essa modalidade é similar ao ilustrado na figura 2. Essa modalidade fornece outro procedimento de comunicação envolvendo a determinação (ou seleção) da arquitetura de comunicação utilizada para o UE 1. A figura 8 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação de acordo com essa modalidade. No procedimento ilustrado na figura 8, a RAN 2 determina um tipo de arquitetura de comunicação utilizado para a transmissão de pacotes de dados para o UE 1, durante um procedimento de anexação do UE 1 à CN 3. Note-se que o procedimento ilustrado na figura 8 difere dos ilustrados nas figuras de 5 a 7 visto que um elemento de informação sobre os tipos de arquitetura de comunicação (por exemplo, um Tipo de Arquitetura Suportado por UE), que indica de forma explícita ou implícita um ou mais tipos de arquitetura de co-municação suportados pelo UE 1, é transmitido a partir de um HSS 5 para a RAN 2 através de CN 3 (por exemplo, MME ou C-SGN).
[000128] As etapas 801 a 804 são similares às etapas 701 a 704 ilustradas na figura 7. No entanto, na etapa 804, o UE 1 não precisa transmitir um elemento de informação NAS (por exemplo, um Tipo de Arquitetura Suportado por UE) indicando um ou mais tipos de arquitetura de comunicação suportados pelo UE 1.
[000129] Na etapa 805, a CN 3 (por exemplo, MME ou C-SGN) realiza um procedimento de autenticação e segurança e, dessa forma, configura a segurança NAS. Na etapa 806, quando a CN 3 (por exemplo, MME ou C-SGN) recebe a informação de autenticação referente ao UE 1 a partir de HSS 5, a CN 3 recebe adicionalmente um ou mais tipos de arquitetura de comunicação suportados pelo UE 1 (por exemplo, o Tipo de Arquitetura Suportado por UE) a partir de HSS 5. HSS 5 gerencia o Tipo de Arquitetura Suportado por UE como informação de assinante referente ao UE 1.
[000130] As etapas 807 a 809 são similares às etapas 705 a 707 na figura 7. As etapas 810 a 812 são similares às etapas 307 a 309 na figura 3, etapas 508 a 510 na figura 5, etapas 608 a 611 na figura 6 ou etapas 709 a 711 na figura 7.
[000131] Quando o segundo tipo de arquitetura de comunicação é utilizado para o UE 1, o procedimento ilustrado na figura 8 pode ser alterado de modo que uma configuração de segurança AS seja realizada como no caso dos outros procedimentos descritos acima. Apesar de a figura 8 ilustrar a transmissão de dados Originados em Móvel (MO), um procedimento similar ao ilustrado na figura 8 pode ser aplicado à transmissão de dados Encerrada em Móvel (MT).
[000132] Um exemplo de configuração de uma rede de comunicação de rádio de acordo com essa modalidade é similar ao ilustrado na figura 2. Essa modalidade fornece outro procedimento de comunicação envolvendo a determinação (ou seleção) da arquitetura de comunicação utilizada para o UE 1 é descrita. A figura 9 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação de acordo com essa modalidade. No procedimento ilustrado na figura 9 a CN 3 determina um tipo de arquitetura de comunicação utilizado para a transmissão de pacotes de dados para o UE 1, durante um procedimento de anexação do UE 1 à CN 3.
[000133] As etapas 901 a 904 são similares às etapas 701 a 704 na figura 7. Isso é, na etapa 904, a CN 3 (por exemplo, MME ou C-SGN) recebe um elemento de informação NAS sobre os tipos de arquitetura de comunicação (por exemplo, um Tipo de Arquitetura Suportado por UE), que indica de forma explícita ou implícita um ou mais tipos de arquitetura de comunicação suportados pelo UE 1, juntamente com uma mensagem de Solicitação de Anexação do UE 1.
[000134] Na etapa 905, a CN 3 determina um tipo de arquitetura de comunicação utilizado para o UE 1 enquanto considera um ou mais tipos de arquitetura de comunicação suportados pelo UE 1 (isso é, o Tipo de Arquitetura Suportado por UE). Em algumas implementações, a CN 3 pode selecionar um tipo de arquitetura de comunicação utilizado para o UE 1 com base em uma capacidade UE padrão que foi pré- configurada no UE 1. Adicionalmente ou alternativamente, a CN 3 pode selecionar um tipo de arquitetura de comunicação utilizado para o UE 1 com base em uma capacidade de rede da RAN 2 (por exemplo, CIoT BS ou eNB). Adicionalmente ou alternativamente, a CN 3 pode selecionar um tipo de arquitetura de comunicação utilizado para o UE 1 com base em um carga na CN 3 (por exemplo, uma carga de Camada de Rede de Transporte S1 (TNL), o número de UEs Conectados, o número de UEs cujo contexto UE está armazenado). Adicionalmente ou alternativamente, a CN 3 pode selecionar um tipo de arquitetura de comunicação utilizado para o UE 1 com base na Qualidade de Serviço (QoS) aplicada ao UE 1 (por exemplo, um Identificador de Classe de QoS (QCI), uma Prioridade de Alocação e Retenção (ARP), um tipo de recurso (uma Taxa de Bit Garantida (GBR) ou um não GBR)).
[000135] Na etapa 906, a CN 3 envia uma mensagem S1AP: Solicitação de Configuração de Contexto Inicial indicando o tipo de arquitetura de comunicação determinado na etapa 905 (por exemplo, um Tipo de Arquitetura Aplicado ou um Tipo de Arquitetura Selecionado) para a RAN 2. A RAN 2 pode enviar uma resposta para a notificação recebida na etapa 906 (etapa 907).
[000136] As etapas 908 a 911 são similares às etapas 306 a 309 na figura 3, etapas 406 a 409 na figura 4, etapas 507 a 510 na figura 5, etapas 607 a 610 na figura 6, ou etapas 708 a 711 na figura 7.
[000137] Quando o segundo tipo de arquitetura de comunicação é utilizado para o UE 1, o procedimento ilustrado na figura 9 pode ser alterado de modo que uma configuração de segurança AS seja realizada como no caso dos outros procedimentos descritos acima. Apesar de a figura 9 ilustrar a transmissão de dados Originados em Móvel (MO), um procedimento similar ao ilustrado na figura 9 pode ser aplicado à transmissão de dados Encerrada em Móvel (MT).
[000138] Um exemplo de configuração de uma rede de comunicação de rádio, de acordo com essa modalidade, é similar ao ilustrado na figura 2. Essa modalidade fornece outro procedimento de comunicação envolvendo a determinação (ou seleção) da arquitetura de comunicação utilizada para o UE 1. A figura 1 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação de acordo com essa modalidade. No procedimento ilustrado na figura 10, a CN 3 determina um tipo de arquitetura de comunicação utilizado para a transmissão de pacotes de dados para o UE 1, durante um procedimento de fixação do UE 1 à CN 3. Note-se que o procedimento ilustrado na figura 10 difere do ilustrado na figura 9 visto que um elemento de informação sobre os tipos de arquitetura de comunicação (por exemplo, um Tipo de Arquitetura Suportada por UE), que indica de forma explícita ou implícita um ou mais tipos de arquitetura de comunicação suportados pelo UE 1, é transmitido a partir de um HSS 5 para a CN 3 (por exemplo, MME ou C-SGN).
[000139] As etapas 1001 a 1006 são similares às etapas 801 a 806 na figura 8. As etapas 1007 a 1009 são similares às etapas 905 a 907 na figura 9. As etapas 1010 a 1012 são similares às etapas 307 a 309 na figura 3, etapas 407 a 409 na figura 4, etapas 508 a 510 na figura 5, etapas 608 a 610 na figura 6, etapas 708 a 711 na figura 7, etapas 810 a 812 na figura 8 ou etapas 909 a 911 na figura 9.
[000140] Quando o segundo tipo de arquitetura de comunicação é utilizado para o UE 1, o procedimento ilustrado na figura 10 pode ser alterado de modo que uma configuração de segurança AS seja realizada como no caso dos outros procedimentos descritos acima. Apesar de a figura 10 ilustrar a transmissão de dados Originada em Móvel (MO), um procedimento similar ao ilustrado na figura 10 pode ser aplicado à transmissão de dados Encerrada em Móvel (MT).
[000141] Um exemplo de configuração de uma rede de comunicação de rádio, de acordo com essa modalidade, é similar ao ilustrado na figura 2. Essa modalidade fornece outro procedimento de comunicação envolvendo a determinação (ou seleção) da arquitetura de comunicação utilizada para o UE 1. As figuras 11 e 12 ilustram um diagrama de sequência ilustrando exemplos de um procedimento de comunicação de acordo com essa modalidade. Nos procedimentos ilustrados nas figuras 11 e 12, o UE 1 determina (ou seleciona) um tipo de arquitetura de comunicação utilizado para a transmissão de pacotes de dados para o UE 1, durante um procedimento de configuração de conexão RRC no qual o UE 1 transita do modo RRC-Inativo (ou outro modo de suspensão) para o modo RRC-Conectado para realizar a transmissão de pacotes de dados após a anexação.
[000142] A figura 11 ilustra um caso no qual o primeiro tipo de arquitetura de comunicação é utilizado para o UE 1. Como já descrito, no primeiro tipo de arquitetura de comunicação, os pacotes de dados de usuário transmitidos ou recebidos pelo UE 1 são transferidos através do plano de controle (por exemplo, uma mensagem NAS transmitida entre o UE e MME/C-SGN). Enquanto isso, a figura 12 ilustra um caso no qual o segundo tipo de arquitetura de comunicação é utilizado para o UE 1. No segundo tipo de arquitetura de comunicação, os pacotes de dados de usuário transmitidos ou recebidos pelo UE 1 são transferidos através do plano de usuário (por exemplo, um suporte EPS inclu-indo um DRB e um túnel de Protocolo de Canalização GPRS (GTP)).
[000143] Com referência à figura 11, o UE 1 determina (seleciona) um tipo de arquitetura de comunicação utilizado para transmissão de pacote de dados para o UE 1 na etapa 1101. A determinação de um tipo de arquitetura de comunicação pode levar em consideração os parâmetros similares aos da etapa 301 na figura 3. No exemplo ilustrado na figura 11, o UE 1 pode determinar (ou selecionar) um tipo de arquitetura de comunicação em cada oportunidade de transmissão. De acordo, o UE 1 pode levar em consideração os parâmetros que mudam dinamicamente em cada oportunidade de transmissão. Por exemplo, o UE 1 pode selecionar um tipo de arquitetura de comunicação de acordo com um acionador de transmissão de dados (por exemplo, mo-Data, mo-ExceptionData, mt-Access, ou mo-Signaling). Adicionalmente ou alternativamente, o UE 1 pode selecionar um tipo de arquitetura de comunicação de acordo com o tipo de um aplicativo que realiza a transmissão de pacotes de dados.
[000144] As etapas 1102 a 1106 são similares às etapas 302 a 305 na figura 3. No entanto, o exemplo da figura 11 ilustra uma transição do modo RRC-Inativo (ou outro modo de suspensão) para o modo RRC-Conectado realizado após a anexação. Adicionalmente, no exemplo ilustrado na figura 11, o UE 1 seleciona o primeiro tipo de arquitetura de comunicação na etapa 1101. Dessa forma, a mensagem NAS inicial transmitida pelo UE 1 na etapa 1105 é uma mensagem NAS portando dados pequenos. Isso é, os dados pequenos "pegam carona" na mensagem NAS inicial.
[000145] Na etapa 1106, a RAN 2 envia uma mensagem NAS inicial (isso é, uma mensagem NAS portando dados pequenos) recuperada da mensagem de Configuração de Conexão RRC Completada para a CN 3 (por exemplo, MME ou C-SGN) utilizando uma mensagem S1AP:UE Inicial. A mensagem NAS inicial (isso é, a mensagem NAS portando os dados pequenos) é embutida em um Elemento de Informação NAS-PDU (IE) da mensagem S1AP:UE Inicial. A RAN 2 pode incorporar um elemento de informação de forma explícita ou implícita indicando o primeiro tipo de arquitetura de comunicação determinado pelo UE 1 na mensagem S1AP:UE Inicial. A RAN 2 pode selecionar, a partir de DCNs na CN 3, uma DCN correspondendo ao primeiro tipo de arquitetura de comunicação determinado pelo UE 1 e enviar a mensagem S1AP:UE Inicial para a DCN selecionada.
[000146] Na etapa 1107, a CN 3 (por exemplo, MME ou C-SGN) descriptografa a mensagem NAS de uplink transmitida a partir de UE 1 para obter os pacotes de dados pequenos. Na etapa 1108, a CN 3 envia o pacote de dados pequenos de acordo com o tipo de dados do pacote de dados pequenos. Quando um ACK ou uma resposta ao pacote pequeno Originado em Móvel deve ser transmitido, a CN 3 recebe um pacote de entrada de dados de downlink de resposta (etapa 1109). Na etapa 1110, a CN 3 criptografa o pacote de dados de downlink e gera uma mensagem NAS de downlink portando o pacote de dados de downlink criptografado. Na etapa 1111, a CN 3 envia uma mensagem S1AP:Transporte NAS DL para a RAN 2. Na etapa 1112, a RAN 2 transmite uma mensagem RRC:Transferência de Informação DL para o UE 1 em um SRB 1. Essa mensagem de Transferência de Informação DL inclui a mensagem NAS de downlink portando o pacote de dados de downlink criptografado desejado para o UE 1.
[000147] A seguir, com referência à figura 12, a etapa 1201 na figura 12 é similar à etapa 1101 na figura 11. No entanto, no exemplo ilustrado na figura 12, o UE 1 seleciona o segundo tipo de arquitetura de comunicação para a transmissão de pacotes de dados para o UE 1.
[000148] As etapas 1202 a 1206 são similares às etapas 1102 a 1106 na figura 11. No entanto, visto que o segundo tipo de arquitetura de comunicação é utilizado no exemplo ilustrado na figura 12, a men- sagem NAS inicial transmitida pelo UE 1 na etapa 1205 é uma mensagem de Solicitação de Serviço.
[000149] Na etapa 1206, a RAN 2 envia uma mensagem NAS inicial (isso é, uma mensagem de Solicitação de Serviço) recuperada da mensagem de Configuração de Conexão RRC Completada para a CN 3 (por exemplo, MME ou C-SGN) utilizando uma mensagem S1AP:UE Inicial. A mensagem NAS Inicial (isso é, a mensagem de Solicitação de Serviço) é embutida em um Elemento de Informação NAS-PDU (IE) da mensagem S1AP:UE Inicial. A RAN 2 pode incorporar um elemento de informação de forma explícita ou implícita indicando o segundo tipo de arquitetura de comunicação determinado pelo UE 1 na mensagem S1AP:UE Inicial. A RAN 2 pode selecionar, a partir de DCNs na CN 3, uma DCN correspondendo ao segundo tipo de arquitetura de comuni-cação determinado pelo UE 1 e enviar a mensagem S1AP:UE Inicial para a DCN selecionada.
[000150] As etapas 1207 a 1211 são similares a um procedimento de estabelecimento de suporte EPS no procedimento de solicitação de serviço existente. Nas etapas 1212 e 1213, o UE 1 transmite dados de uplink em um suporte de uplink através de um S-GW 6 e RAN 2 e recebe dados de downlink em um suporte de downlink através de S-GW e RAN 2.
[000151] Na etapa 1214, o UE 1, a RAN 2, e a CN 3 suspendem a conexão RRC. O UE 1 transita do modo RRC-Conectado para o modo RRC-Inativo (ou outro modo de suspensão) e retém informação sobre a conexão RRC (por exemplo, um Contexto de Segurança de Extrato de Acesso, uma informação relacionada com suporte (incluindo informação de estão RoHC), e parâmetros L2/1 quando aplicável) enquanto está no modo RRC-Inativo (ou outro modo de suspensão). De forma similar, a RAN 2 retém informação sobre a conexão RRC para o UE 1 (por exemplo, um Contexto de Segurança de Extrato de Acesso, in- formação relacionada com suporte (incluindo informação de estado RoHC), e parâmetros L2/1 quando aplicável). Adicionalmente, a RAN 2 e a CN 3 retêm os Contextos UE S1AP. Adicionalmente, a RAN 2 retém os endereços de túnel S1-U. Dessa forma, o UE 1, a RAN 2 e a CN 3 podem reutilizar a informação obtida a partir da conexão RRC anterior para a configuração da conexão RRC subsequente.
[000152] Apesar de as figuras 11 e 12 ilustrarem a transmissão de dados Originada em Móvel (MO), procedimentos similares aos ilustrados nas figuras 11 e 12 podem ser aplicados à transmissão de dados Encerrada em Móvel (MT).
[000153] O procedimento ilustrado na figura 12 pode ser modificado como segue. Em algumas implementações, a mensagem S1AP-UE Inicial na etapa 1206 pode indicar um identificador de ponto final de túnel de downlink utilizado no segundo tipo de arquitetura de comunicação. O identificador de ponto final de túnel de downlink especifica um ponto final do túnel na RAN 2 de um suporte entre a RAN 2 e a CN 3 que é utilizado para a transmissão de pacotes de dados para o UE 1 no segundo tipo de arquitetura de comunicação. O identificador de ponto final de túnel de downlink pode ser um S1 eNB TEID (isso é, um S1 TEID (DL)) de um suporte S1 (isso é, um túnel GTP). Adicional-mente, a mensagem S1AP:UE Inicial na etapa 1206 pode indicar um endereço da RAN 2 (por exemplo, um endereço eNB) utilizado para a transmissão de pacotes de dados para o UE 1 no segundo tipo de arquitetura de comunicação. Dessa forma, é possível se omitir a transmissão de uma mensagem de Modificar Solicitação de Suporte da MME para S-GW e uma mensagem para Modificar Solicitação de Suporte de S-GW para MME, que são necessárias no procedimento de estabelecimento de suporte EPS existente. Adicionalmente ou alternativamente, é possível se omitir a transmissão de uma mensagem de Resposta de Configuração de Contexto Inicial do eNB para a MME,que é necessário no procedimento de estabelecimento de suporte EPS existente. Em CIoT, a RAN 2 e a CN 3 precisam ter uma capacidade de comunicação com um grande número de dispositivos CIoT. Pela eliminação da transmissão dessas mensagens de sinalização, é possível se contribuir para a redução da carga relacionada com CIoT na RAN 2 e CN 3.
[000154] Nos exemplos ilustrados nas figuras 11 e 12, o UE 1 determina um tipo de arquitetura de comunicação utilizado para a transmissão de pacotes de dados para o UE 1 e transmitir para a RAN 2 uma mensagem de Solicitação de Conexão RRC incluindo uma causa do estabelecimento indicando o tipo de arquitetura de comunicação determinado. De acordo, os exemplos ilustrados nas figuras 11 e 12 podem fornecer as mesmas vantagens que os exemplos ilustrados na figura 3. Adicionalmente, os exemplos ilustrados nas figuras 11 e 12 permitem que o UE 1 determine um tipo de arquitetura de comunicação utilizado para a transmissão de pacotes de dados para o UE 1, durante um procedimento de configuração de conexão RRC no qual o UE 1 transita do modo RRC-Inativo (ou outro modo de suspensão) para o modo RRC-Conectado para realizar a transmissão de pacotes de dados após a anexação.
[000155] Um exemplo de configuração de uma rede de comunicação de rádio de acordo com essa modalidade é similar ao ilustrado na figura 2. Essa modalidade fornece outro procedimento de comunicação envolvendo a determinação (ou seleção) da arquitetura de comunicação utilizada para o UE 1. As figuras 13 e 14 ilustram um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação de acordo com essa modalidade. Nos procedimentos ilustrados nas figuras 13 e 14, o UE 1 determina um tipo de arquitetura de comunicação utilizado para a transmissão de pacotes de dados para o UE 1, durante um procedimento de configuração de conexão RRC no qual o UE 1 transita do modo RRC-Inativo (ou outro modo de suspensão) para o modo RRC-Conectado para realizar a transmissão de pacotes de dados depois da anexação. A figura 13 ilustra um caso no qual o primeiro tipo de arquitetura de comunicação é utilizado para o UE 1. Enquanto isso, a figura 14 ilustra um caso no qual o segundo tipo de arquitetura de comunicação é utilizado para o UE 1. Note-se que os procedimentos nas figuras 13 e 14 são diferentes dos procedimentos nas figuras 11 e 12 visto que o tipo de arquitetura de comunicação determinado pelo UE 1 é enviado para a RAN 2 por uma mensagem de Configuração de Conexão RRC Completada.
[000156] Com referência à figura 13, as etapas 1301 a 1312 são similares às etapas 1101 a 1112 na figura 11. No entanto, no procedimento na figura 13, o UE 1 transmite, para a RAN 2, um elemento de Informação de Assistência UE (IE) indicando de forma explícita ou implícita o primeiro tipo de arquitetura de comunicação determinado pelo UE 1, utilizando uma mensagem de Configuração de Conexão RRC Completada (etapa 1305) como no procedimento na figura 4.
[000157] A seguir, com referência à figura 14, as etapas 1401 a 1414 são similares às etapas 1201 a 1214 na figura 12. No entanto, no procedimento na figura 14, o UE 1 transmite, para a RAN 2, um Elemento de Informação de Assistência UE (IE) indicando de forma explícita ou implícita o segundo tipo de arquitetura de comunicação determinado pelo UE 1, utilizando uma mensagem de Configuração de Conexão RRC Completada (etapa 1405) como no procedimento na figura 4.
[000158] Apesar de as figuras 13 e 14 ilustrarem a transmissão de dados Originadas em Móvel (MO), os procedimentos similares aos ilustrados na figura 13 e 14 podem ser aplicados à transmissão de dados Encerrada em Móvel (MT).
[000159] Nos exemplos ilustrados nas figuras 13 e 14, o UE 1 deter- mina um tipo de arquitetura de comunicação utilizado para a transmissão de pacotes de dados para o UE 1 e transmite para a RAN 2 uma mensagem de Configuração de Conexão RRC Completada incluindo um IE de assistência UE indicando o tipo de arquitetura de comunicação determinado. De acordo, os exemplos ilustrados nas figuras 13 e 14 podem fornecer as mesmas vantagens que o exemplo ilustrado na figura 4. Adicionalmente, o exemplo ilustrado nas figuras 13 e 14 permite que o UE 1 determine um tipo de arquitetura de comunicação utilizado para a transmissão de pacotes de dados para o UE 1 durante um procedimento de configuração de conexão RRC onde o UE 1 transita do modo RRC-Inativo (ou outro modo de suspensão) para o modo RRC-Conectado para realizar a transmissão de pacotes de dados após a anexação.
[000160] Um exemplo de configuração de uma rede de comunicação de rádio de acordo com essa modalidade é similar ao ilustrado na figura 2. Essa modalidade fornece outro procedimento de comunicação envolvendo a determinação (ou seleção) da arquitetura de comunicação utilizada para o UE 1. As figuras 15 e 16 ilustram um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação de acordo com essa modalidade. Nos procedimentos ilustrados nas figuras 15 e 16, a RAN 2 determina um tipo de arquitetura de comunicação utilizado para a transmissão de pacotes de dados para o UE 1, durante uma configuração de conexão RRC na qual o UE 1 transita do modo RRC-Inativo (ou outro modo de suspensão) para o modo RRC-Conectado para realizar a transmissão de pacotes de dados após a anexação. A figura 15 ilustra um caso no qual o primeiro tipo de arquitetura de comunicação é utilizado para o UE 1. Enquanto isso, a figura 16 ilustra um caso no qual o segundo tipo de arquitetura de comunicação é utilizado para o UE 1. Note-se que os procedimen- tos nas figuras 15 e 16 são diferentes dos procedimentos nas figuras 11 e 12 visto que a RAN 2 determina o tipo de arquitetura de comunicação.
[000161] Com referência à figura 15, as etapas 1501 a 1505 são similares às etapas 601 a 605 na figura 6. No entanto, o exemplo na figura 15 ilustra uma transição do modo RRC-Inativo (ou outro modo de suspensão) para o modo RRC-Conectado realizado após a anexação. Adicionalmente, no exemplo ilustrado na figura 15, a RAN 2 seleciona o primeiro tipo de arquitetura de comunicação para o UE 1 na etapa 1503. Dessa forma, a mensagem NAS inicial transmitida pelo UE 1 na etapa 1505 é uma mensagem NAS portando dados pequenos. Isso é, os dados pequenos "pegam carona" na mensagem NAS inicial. A mensagem de Configuração de Conexão RRC na etapa 1504 pode indicar de forma explícita ou implícita o primeiro tipo de arquitetura de comunicação determinado pela RAN 2 na etapa 1503 (por exemplo, um Tipo de Arquitetura Aplicada ou um Tipo de Arquitetura Selecionada).
[000162] Quando a RAN 2 indica explicitamente um tipo de arquitetura de comunicação, a RAN 2 pode transmitir para o UE 1 uma mensagem de Configuração de Conexão RRC incluindo um elemento de informação de camada AS (por exemplo, camada RRC) ou um elemento de informação de camada NAS indicando o tipo de arquitetura de comunicação. Quando um elemento de informação NAS indicando o tipo de arquitetura de comunicação é transmitido, a camada NAS do UE 1 pode enviar informação indicando o tipo de arquitetura de comunicação a ser utilizado para a camada AS do UE 1, ou pode iniciar a transmissão de dados de acordo com o tipo de arquitetura de comunicação. Por outro lado, quando a RAN 2 indica implicitamente o tipo de arquitetura de comunicação, a RAN 2 pode notificar o UE 1 sobre o tipo de arquitetura de comunicação selecionado pela incorporação da informação de configuração para o tipo de arquitetura de comunicação selecionado na mensagem de Configuração de Conexão RRC.
[000163] Na etapa 1506, a RAN 2 envia uma mensagem NAS inicial (isso é, uma mensagem NAS portando dados pequenos) recuperada a partir da mensagem de Configuração de Conexão RRC Completada para a CN 3 (por exemplo, MME ou C-SGN) utilizando uma mensagem S1AP:UE Inicial. A mensagem NAS inicial (isso é, a mensagem NAS portando dados pequenos) é embutida em um Elemento de Informação NAS-PDU (IE) da mensagem S1AP:UE Inicial. A RAN 2 pode incorporar um elemento de informação indicando o tipo de arquitetura de comunicação determinado na etapa 1503 (por exemplo, um Tipo de Arquitetura Aplicada ou um Tipo de Arquitetura selecionada) na mensagem S1AP:UE Inicial. A RAN 2 pode selecionar, a partir das DCNs na CN 3, uma DCN correspondendo ao tipo de arquitetura de comunicação determinado na etapa 1503 e enviar a mensagem S1AP:UE Ini-cial portando a mensagem NAS inicial (isso é, a mensagem de Solicitação de Anexação) para a DCN selecionada.
[000164] As etapas 1507 a 1512 são similares às etapas 1107 a 1112 na figura 11 ou etapas 1307 a 1312 na figura 13.
[000165] A seguir, com referência à figura 16, as etapas 1601 a 1606 são similares às etapas 1501 a 1505 na figura 15. No entanto, na etapa 1603, a RAN 2 seleciona o segundo tipo de arquitetura de comunicação para o UE 1. Dessa forma, a mensagem NAS inicial transmitida pelo UE 1 na etapa 1605 é uma mensagem de Solicitação de Serviço. A mensagem de Configuração de Conexão RRC na etapa 1604 pode indicar de forma explícita ou implícita o segundo tipo de arquitetura de comunicação determinado pela RAN 2 na etapa 1603 (por exemplo, um Tipo de Arquitetura Aplicada ou um Tipo de Arquitetura Selecionada).
[000166] As etapas 1606-1614 são similares às etapas 1206 a 1214 na figura 12 ou etapas 1406 a 1414 na figura 14.
[000167] Apesar de as figuras 15 e 16 ilustrarem a transmissão de dados Originadas em Móvel (MO), procedimentos similares aos ilustrados nas figuras 15 e 16 podem ser aplicados à transmissão de dados Encerrada em Móvel (MT).
[000168] O exemplo ilustrado nas figuras 15 e 16 permite que a RAN 2 determine um tipo de arquitetura de comunicação utilizado para a transmissão de pacotes de dados para o UE 1, durante um procedimento de configuração de conexão RRC no qual o UE 1 transita do modo RRC-Inativo (ou outro modo de suspensão) para o modo RRC- Conectado para realizar a transmissão de pacotes de dados após a anexação.
[000169] Um exemplo de configuração de uma rede de comunicação de rádio, de acordo com essa modalidade, é similar ao ilustrado na figura 2. No entanto, a CN 3 inclui uma pluralidade de redes núcleo (dedicadas). A RAN 2 determina um tipo de arquitetura de comunicação utilizado para a transmissão de pacotes de dados para o UE 1 e seleciona a partir de uma pluralidade de redes núcleo (dedicadas) incluídas em CN 3, uma rede núcleo (dedicada) correspondente ao tipo de arquitetura de comunicação determinada. Adicionalmente, a RAN 2 é configurada para enviar uma mensagem de Extrato de Não Aces- so(NAS) para a rede núcleo selecionada.
[000170] A figura 17 é um diagrama de sequência ilustrando um exemplo de um procedimento de comunicação de acordo com essa modalidade. No exemplo ilustrado na figura 17, a CN 3 inclui uma primeira rede núcleo (dedicada) ((D)CN-1 3A) correspondendo ao primeiro tipo de arquitetura de comunicação e uma segunda rede núcleo (dedicada) ((D)CN-2 3B) correspondendo ao segundo tipo de arquitetura de comunicação.
[000171] A etapa 1701 é similar à etapa 504 na figura 5. Isso é, o UE 1 transmite uma mensagem de Configuração de Conexão RRC Completada durante um procedimento de configuração de conexão RRC para anexação inicial. A mensagem de Configuração de Conexão RRC Completada na etapa 1701 inclui um elemento de informação indicando de forma explícita ou implícita um ou mais tipos de arquitetura de comunicação suportados pelo UE 1 (por exemplo, um Tipo de Arquitetura Suportado por UE). Esse elemento de informação é informação AS (RRC).
[000172] Na etapa 1702, de forma similar à etapa 505 na figura 5, a RAN 2 determina um tipo de arquitetura de comunicação utilizado para o UE 1 enquanto considera um ou mais tipos de arquitetura de comunicação suportados pelo UE 1. Adicionalmente, a RAN 2 seleciona, a partir de uma pluralidade de redes núcleo (dedicadas) incluídas na CN 3, uma rede núcleo (dedicada) correspondendo ao tipo de arquitetura de comunicação determinado. Isso é, quando a RAN 2 seleciona o primeiro tipo de arquitetura de comunicação para o UE 1, a mesma seleciona CN-1 3A e envia uma mensagem S1AP:UE Inicial para CN-1 3A (etapa 1703). Quando a RAN 2 seleciona o segundo tipo de arquitetura de comunicação para o UE 1, a mesma seleciona CN-2 3B e envia uma mensagem UE Inicial para CN-2 3B (etapa 1704). Essa mensagem UE Inicial pode indicar o tipo de arquitetura de comunicação selecionado pela RAN 2 (por exemplo, um Tipo de Arquitetura Aplicada ou um Tipo de Arquitetura Selecionada).
[000173] As etapas 1705 a 1708 são similares às etapas 507 a 510 na figura 5. A mensagem de Aceitação de Anexação na etapa 1706, a mensagem de Liberação de Conexão RRC na etapa 1707, ou outra mensagem NAS de downlink transmitida a partir da CN 3 (isso é, CN-1 3A ou CN-2 3B) para o UE 1 pode indicar de forma explícita ou implícita o tipo de arquitetura de comunicação utilizado para o UE 1.
[000174] Quando o UE 1 realiza a transmissão de dados após a anexação, de acordo com o procedimento ilustrado na figura 17, o UE 1 pode indicar a informação sobre a CN dedicada com a qual o UE 1 foi registrado (isso é, informação sobre a MME ou C-SGN), utilizando o Elemento de Informação MME Registrado (IE) incluído na mensagem de Configuração de Conexão RC Completada. A RAN 2 pode utilizar o IE MME Registrado incluído na mensagem de Configuração de Conexão RRC Completada para selecionar um tipo de arquitetura de comunicação aplicado ao UE 1 e selecionar uma CN (dedicada). Isso é, quando o IE MME Registrado indica um nó NAS (por exemplo, MME/C-SGN) de CN-1 3A, a RAN 2 seleciona o primeiro tipo de arquitetura de comunicação e CN-1 3A para o UE 1, ao passo que quando IE MME Registrado indica um nó NAS (por exemplo, MME/C-SGN) de CN-2 3B, a RAN 2 seleciona o segundo tipo de arquitetura de comunicação e CN-2 3B para o UE 1. Um IE C-SGN Registrado, um ID DCN Registrado, ou um Tipo de Utilização UE pode ser utilizado, em adição a ou ao invés do IE MME Registrado.
[000175] No exemplo ilustrado na figura 17, a RAN 2 determina um tipo de arquitetura de comunicação utilizado para o UE 1 e seleciona uma rede núcleo (dedicada) para a qual uma mensagem UE Inicial deve ser transmitida. Isso, dessa forma, permite que a RAN 2 selecione uma rede núcleo (dedicada) adequada de acordo com uma determinação dinâmica na RAN 2 de um tipo de arquitetura de comunicação utilizado para o UE 1.
[000176] Um exemplo de configuração de uma rede de comunicação de rádio, de acordo com essa modalidade, é similar ao ilustrado na figura 2. No entanto, a CN 3 inclui uma pluralidade de redes núcleo (dedicadas). A RAN 2 é configurada para determinar um tipo de arquitetura de comunicação utilizado para a transmissão de pacotes de da- dos para o UE 1. A CN 3 é configurada para realizar o novo direcionamento (ou redirecionamento) de uma mensagem UE Inicial de modo que a mensagem UE Inicial seja transmitida para uma rede núcleo adequada (dedicada) correspondendo ao tipo de arquitetura de comunicação determinado pela RAN 2.
[000177] A figura 18 é um diagrama em sequência ilustrando um exemplo de um procedimento de comunicação de acordo com essa modalidade. No exemplo ilustrado na figura 18, a CN 13 inclui uma primeira rede núcleo (dedicada) ((D)CN-1 3A) correspondendo ao primeiro tipo de arquitetura de comunicação e uma segunda rede núcleo (dedicada) ((D)CN-2 3B) correspondendo ao segundo tipo de arquitetura de comunicação.
[000178] As etapas 1801 e 1805 são similares às etapas 504 e 505 na figura 5. A RAN 2 recebe uma mensagem de Configuração de Conexão RRC Completada incluindo uma mensagem NAS inicial a partir do UE 1. A RAN 2, então, determina um tipo de arquitetura de comunicação utilizado para o UE 1 enquanto considera um ou mais tipos de arquitetura de comunicação suportados pelo UE 1.
[000179] Na etapa 1803, a RAN 2 envia uma mensagem S1AP:UE Inicial para uma rede núcleo pré-designada ou selecionada de forma arbitrária (dedicada). Essa mensagem UE Inicial inclui um elemento de informação indicando de forma explícita ou implícita o tipo de arquitetura de comunicação utilizado para o UE 1 (por exemplo, um Tipo de Arquitetura Aplicada ou um Tipo de Arquitetura Selecionada). No exemplo ilustrado na figura 18, a RAN 2 envia a mensagem UE Inicial para a rede núcleo (dedicada) CN-2 3B. A rede núcleo pré-designada (dedicada) pode ser, por exemplo, uma rede núcleo que suporta um tipo de arquitetura de comunicação padrão.
[000180] Na etapa 1804, um nó NAS (por exemplo, MME/C-SGN) localizado na CN 3 (isso é, CN-2 3B nesse exemplo) recebe a mensa- gem UE Inicial da RAN 2 e se refere ao elemento de informação indicando o tipo de arquitetura de comunicação (por exemplo, um Tipo de Arquitetura Aplicada ou um Tipo de Arquitetura Selecionada) incluído na mensagem UE Inicial recebida. Quando o tipo de arquitetura de comunicação utilizado para o UE 1 é associado com CN-2 3B, o nó NAS localizado em CN-2 3B continua o processo de anexação com base na mensagem de Solicitação de Anexação incluída na mensagem UE Inicial. Por outro lado, quando o tipo de arquitetura de comunicação utilizado para o UE 1 é associado com outra rede núcleo (de-dicada) (isso é, CN-1 3A nesse exemplo), o nó NAS localizado na CN- 2 3B solicita que a RAN 2 redirecione a mensagem UE Inicial para CN- 1 3A. Especificamente, como ilustrado na figura 18, a CN-2 3B envia uma mensagem S1AP:Redirecionar Solicitação de Mensagem NAS para RAN 2. Essa mensagem de Redirecionar Solicitação de Mensagem NAS inclui um identificador da rede núcleo (dedicada) para o qual a mensagem UE Inicial é enviada (por exemplo, um ID de Grupo MME, um ID de Grupo C-SGN, um ID de Grupo DCN e uma Identidade Temporária Singular Global Adicional (GUTI)).
[000181] Na etapa 1804, para se determinar o redirecionamento da mensagem UE Inicial, a CN 3 pode considerar adicionalmente dados de assinatura do UE 1 recuperados a partir de HSS 5 (por exemplo, uma Capacidade UE ou um Tipo de Utilização UE (por exemplo, C- IoT, um MTC geral, ou um MTC tolerante a retardo)).
[000182] Na etapa 1805, depois do recebimento da mensagem S1AP: Redirecionar Solicitação de Mensagem NAS, a RAN 2 redireciona a mensagem UE Inicial para a rede núcleo (a CN-1 3A, nesse exemplo) designada na mensagem de Redirecionar Solicitação de Mensagem NAS.
[000183] As etapas 1806 a 1809 são similares às etapas 1704 a 1708 na figura 17. A mensagem de Aceitação de Anexação na etapa 1807, a mensagem de Liberação de Conexão RRC na etapa 1808, ou outra mensagem NAS de downlink transmitida a partir da CN 3 (isso é, CN-1 3A ou CN-2 3B) para o UE 1 pode indicar explicitamente ou implicitamente o tipo de arquitetura de comunicação utilizado para o UE 1.
[000184] Quando o UE 1 realiza a transmissão de dados depois da anexação de acordo com o procedimento ilustrado na figura 18, o UE 1 pode indicar a informação sobre uma CN dedicada com a qual o UE 1 foi registrado (isso é, informação sobre a MME ou C-SGN), utilizando um Elemento de Informação MME Registrado (IE) incluído na mensagem de Configuração de Conexão RRC Completada. A RAN 2 pode utilizar o IE MME Registrado incluído na mensagem de Configuração de Conexão RRC Completada para selecionar um tipo de arquitetura de comunicação aplicado ao UE 1 e selecionar uma CN (dedicada). Isso é, quando o IE MME Registrado indicar um nó NAS (por exemplo, MME/C-SGN) da CN-1 3A, a RAN 2 seleciona o primeiro tipo de arquitetura de comunicação e CN-1 3A para o UE 1, ao passo que quando o IE MME Registrado indicar um nó NAS (por exemplo, MME/C-SGN) da CN-2 3B, a RAN 2 seleciona o segundo tipo de arquitetura de comunicação e a CN-2 3B para o UE 1.
[000185] No exemplo ilustrado na figura 18, a CN 3 reconhece o tipo de arquitetura de comunicação determinado pela RAN 2 e redireciona a mensagem UE Inicial de acordo com o tipo de arquitetura de comunicação determinado pela RAN 2. Dessa forma, permite que a CN 3 manuseie a mensagem UE Inicial em uma rede núcleo adequada (dedicada) de acordo com uma determinação dinâmica na RAN 2 do tipo de arquitetura de comunicação utilizado para o UE 1.
[000186] Um exemplo de configuração de uma rede de comunicação de rádio, de acordo com essa modalidade, é similar a um ilustrado na figura 2. No entanto, a CN 3 inclui uma pluralidade de redes núcleo (dedicadas). A CN 3 é configurada para determinar um tipo de arquitetura de comunicação utilizada para a transmissão de pacotes de dados para o UE 1 e realizar o redirecionamento de uma mensagem UE Inicial de modo que a mensagem UE Inicial seja transmitida para uma rede núcleo adequada (dedicada) correspondendo ao tipo de arquitetura de comunicação determinado pela CN 3.
[000187] A figura 19 é um diagrama em sequência ilustrando um exemplo de um procedimento de comunicação, de acordo com essa modalidade. No exemplo ilustrado na figura 19, a CN 3 inclui uma primeira rede núcleo (dedicada) ((D) CN-1 3A) correspondendo ao primeiro tipo de arquitetura de comunicação e uma segunda rede núcleo (dedicada) ((D) CN-2 3B) correspondendo ao segundo tipo de arquitetura de comunicação. O procedimento ilustrado na figura 19 é diferente do ilustrado na figura 18 visto que a CN 3 determina o tipo de arquitetura de comunicação utilizado para o UE 1.
[000188] As etapas 1901 e 1902 são similares à etapa 904 na figura 9. Isso é, na etapa 1901, o UE 1 transmite para a RAN 2 uma mensagem de Configuração de Conexão RRC Completada portando a informação NAS Dedicada incluindo uma mensagem NAS inicial (isso é, uma mensagem de Solicitação de Anexação) e um ou mais tipos de arquitetura de comunicação suportados pelo UE 1 (por exemplo, um Tipo de Arquitetura Suportada por UE). Na etapa 1902, a RAN 2 recupera a informação NAS dedicada a partir da mensagem de Configuração de Conexão RRC Completada. A RAN 2 envia então uma mensagem S1AP:UE Inicial portando uma NAS-PDU incluindo a informação NAS dedicada recuperada para uma rede núcleo pré-designada ou selecionada de forma arbitrária (dedicada). No exemplo ilustrado na figura 19, a RAN 2 envia a mensagem UE Inicial para a rede núcleo (dedicada) CN-2 3B.
[000189] A etapa 1903 é similar à etapa 905 na figura 9. Isso é, um nó NAS (por exemplo, MME/C-SGN) localizado na CN 3 (isso é, a CN- 2 3B nesse exemplo) determina um tipo de arquitetura de comunicação utilizado para o UE 1 enquanto considera um ou mais tipos de arquitetura de comunicação suportados pelo UE 1 (por exemplo, o Tipo de Arquitetura Suportada por UE). Para se determinar o tipo de arquitetura de comunicação, o nó NAS localizado na CN-2 3B pode considerar adicionalmente os dados de assinatura do UE 1 recuperados a partir de HSS 5 (por exemplo, uma Capacidade do UE ou um Tipo de Utilização de UE).
[000190] As etapas 1904 a 1909 são similares às etapas 1804 a 1809 na figura 18. No entanto, a mensagem S1AP:Redirecionar Solicitação de Mensagem NAS na etapa 1904 pode incluir um elemento de informação indicando explicitamente ou implicitamente o tipo de arquitetura de comunicação utilizado para UE 1 determinado por CN-2 3B (por exemplo, um Tipo de Arquitetura Aplicada ou um Tipo de Arquitetura Selecionada). Dessa forma, a RAN 2 pode reconhecer o tipo de arquitetura de comunicação utilizado para o UE 1.
[000191] No exemplo ilustrado na figura 19, a CN 3 determina um tipo de arquitetura de comunicação para o UE 1 e redireciona uma mensagem UE Inicial de acordo com o tipo de arquitetura de comunicação determinado. É, dessa forma, possível permitir que a CN 3 manuseie a mensagem UE Inicial em uma rede núcleo adequada (dedicada) de acordo com uma determinação dinâmica na CN 3 do tipo de arquitetura de comunicação utilizado para o UE 1.
[000192] O método de transmissão de um elemento de informação indicando explicitamente ou implicitamente um tipo de arquitetura de comunicação a partir do UE 1 para a RAN 2 não está limitado aos métodos descritos nas modalidades acima. Isso é, não está limitado aos métodos utilizando uma mensagem RRC (por exemplo, Solicitação de Conexão RRC ou Configuração de Conexão RRC Completada).
[000193] Por exemplo, o UE 1 pode transmitir o elemento de informação (por exemplo, IE de assistência UE) indicando um tipo de arquitetura de comunicação, utilizando um cabeçalho RLC, um cabeçalho MAC, ou um Elemento de Controle MAC (CE MAC) em uma camada inferior à RRC (isso é, RLC ou MAC). Adicionalmente ou alternativamente, o UE 1 pode transmitir informação indicando uma omissão de um processo PDCP (por exemplo, um processo de segurança AS) para a RAN 2, utilizando um cabeçalho RLC, um cabeçalho MAC, ou um CE MAC. Mais especificamente, quando o primeiro tipo de arquitetura de comunicação envolve uma omissão de um processo PDCP, o UE 1 pode transmitir pelo menos um dentre um elemento de informação in-dicando o primeiro tipo de arquitetura de comunicação e um elemento de informação indicando a omissão do processo PDCP, utilizando um CE MAC.
[000194] Por exemplo, quando o UE 1 determina (seleciona) o primeiro tipo de arquitetura de comunicação na etapa 401 na figura 4, o UE 1 pode omitir o processo PDCP para SRB 1 para transmitir a mensagem de Configuração de Conexão RRC Completada (etapa 405). De acordo, o UE 1 transmite pelo menos um dentre um elemento de informação indicando o primeiro tipo de arquitetura de comunicação e o elemento de informação indicando a omissão do processo PDCP, utilizando um CE MAC. Pela utilização de CE MAC, a RAN 2 pode reconhecer, em seu processo MAC antes de seu processo PDCP, que o processo PDCP no UE 1 foi omitido para a mensagem recebida do UE 1 (incluindo Configuração de Conexão RRC Completada).
[000195] Apesar de as modalidades descritas acima fornecerem exemplos nos quais um procedimento de acesso aleatório envolvendo a transmissão de um preâmbulo de acesso randômico é realizado quando o UE 1 transita do modo RRC-Inativo (ou outro modo de suspensão) para o modo RRC-Conectado, a presente descrição não está limitada a tais exemplos. Outros procedimentos de acesso randômico podem ser implementados no UE 1 e na RAN 2. Em algumas implementações, um UE 1 pode transmitir uma mensagem pequena (ou curta), em vez de um preâmbulo de acesso randômico (isso é, um preâmbulo RACH), em um RACH. Nesse caso, a mensagem transmitida no RACH pode indicar um tipo de arquitetura de comunicação que é determinado (ou selecionado) ou suportado pelo UE 1. Permite que o UE 1 informe a RAN 2 sobre o tipo de arquitetura de comunicação determinado (ou selecionado) ou suportado pelo UE 1, antes do estabelecimento de uma conexão RRC. Dessa forma, por exemplo, a RAN 2 pode gerar uma mensagem de resposta RA enquanto considera o tipo de arquitetura de comunicação recebido do UE 1. A mensagem de resposta RA pode incluir um indicador de backoff determinado com base no tipo de arquitetura de comunicação recebida a partir do UE 1. Décima Sétima Modalidade
[000196] Os recursos RACH que são utilizados pelo UE 1 quando o UE 1 transita do modo RRC-Inativo (ou outro modo de suspensão) para o modo RRC-Conectado pode ser alocado respectivamente a uma pluralidade de tipos de arquitetura de comunicação. Nesse caso, o UE 1 pode utilizar um recurso RACH particular para a primeira transmissão RACH contendo um preâmbulo ou uma mensagem pequena (ou curta) para indicar implicitamente um tipo de arquitetura de comunicação determinado (ou selecionado) ou suportado pelo UE 1. Permite que o UE 1 informe à RAN 2 sobre o tipo de arquitetura de comunicação determinado (ou selecionado) ou suportado pelo UE 1, antes do estabelecimento de uma conexão RRC. Dessa forma, por exemplo, a RAN 2 pode gerar uma mensagem de resposta RA enquanto conside- ra o tipo de arquitetura de comunicação recebido a partir do UE 1. A mensagem de resposta RA pode incluir um indicador de backoff determinado com base no tipo de arquitetura de comunicação recebido do UE 1.
[000197] As modalidades descritas acima podem ser aplicadas a uma ou a ambas as comunicações NB-IoT e LTE eMTC. Adicionalmente, as modalidades descritas acima podem ser aplicadas à comunicação LTE, comunicação LTE-Avançada, e outra comunicação UE de acordo com as versões modificadas desses padrões.
[000198] Um exemplo de configuração de uma rede de comunicação de rádio, de acordo com essa modalidade, é similar ao ilustrado na figura 2. Note-se que o UE 1, de acordo com essa modalidade, pode ser um dispositivo CIoT (por exemplo, NB-IoT ou LTE eMTC), ou pode ser um UE em conformidade com LTE, LTE-Avançada ou versões modificadas desses padrões. Essa modalidade fornece exemplos de mobilidade em um caso no qual um dos tipos de arquitetura de comunicação descritos acima é aplicado ao UE 1.
[000199] A mobilidade do UE 1 inclui uma mudança de célula no modo inativo (por exemplo, o modo RRC-Inativo ou outro modo de suspensão) (isso é, mobilidade de modo inativo) e uma mudança de célula no modo conectado (por exemplo, RRC-Conectado) (isso é, mobilidade de modo conectado). A mobilidade de modo inativo inclui um procedimento de nova seleção de célula no modo inativo. A mobilidade de modo conectado inclui os procedimentos de transferência de retorno e de avanço no modo conectado (por exemplo, liberação de RRC com redirecionamento).
[000200] A rede de comunicação de rádio de acordo com essa modalidade pode não precisar suportar a mobilidade dos UEs 1 aos quais pelo menos um dentre uma pluralidade de tipos de arquitetura de co- municação, incluindo o primeiro e segundo tipos de arquitetura de co-municação, é aplicado. Note-se que "mobilidade de não suporte" significa que o tipo de arquitetura de comunicação e sua configuração que foi utilizada para o UE 1 antes da mudança de célula não são levados em consideração na determinação ou seleção de um tipo de arquitetura de comunicação a ser aplicado ao UE 1 depois da mudança de célula.
[000201] Em algumas implementações, a RAN 2 pode desativar as funções para a mobilidade no modo RRC-Conectado (por exemplo, transferência e redirecionamento) para o UE 1 ao qual o primeiro (ou segundo) tipo de arquitetura de comunicação é aplicado. Em outras palavras, o UE 1 pode desativar funções (por exemplo, relatório de medição, transferência e redirecionamento) para mobilidade no modo RRC-Conectado. Adicionalmente ou alternativamente, a RAN 2 pode desativar funções para a mobilidade no modo RRC-Inativo (por exemplo, nova seleção de célula) para o UE 1 ao qual o segundo tipo de arquitetura de comunicação (ou primeiro) é aplicado. Em outras palavras, o UE 1 pode desativar as funções (por exemplo, nova seleção e medição de célula) para mobilidade no modo RRC-Inativo.
[000202] Em algumas implementações, funções para a mobilidade no modo RRC-Inativo e modo RRC-Conectado podem ser ativadas para o UE 1 ao qual o primeiro tipo de arquitetura de comunicação (ou segundo) é aplicado. Nesse caso, o UE 1 pode operar como segue para mudar uma célula no modo RRC-Inativo ou modo RRC-Conectado.
[000203] Por exemplo, depois da realização de uma nova seleção de célula, o UE 1 pode liberar (ou eliminar) a informação referente ao tipo de arquitetura de comunicação que foi configurado em (ou aplicado ao) UE 1 em uma célula antes da nova seleção de célula.
[000204] Por exemplo, durante um procedimento de transferência no modo RRC-Conectado (isso é, transferência de retorno), o UE 1 pode liberar (ou eliminar) a informação sobre o tipo de arquitetura de comunicação que foi configurado em (ou aplicado ao) UE 1 em resposta ao recebimento de uma instrução de transferência do nó RAN fonte (por exemplo, eNB fonte ou CIoT BS fonte) localizado na RAN 2. A instrução de transferência pode ser, por exemplo, uma mensagem de Reconfiguração de Conexão RRC incluindo um IE de mobilityControlInfo.
[000205] Por exemplo, durante uma liberação RRC com procedimento de redirecionamento no modo RRC-Conectado, o UE 1 pode liberar (ou eliminar) informação sobre o tipo de arquitetura de comunicação que foi configurado no (ou aplicado ao) UE 1 em resposta ao recebimento, a partir do nó RAN fonte (por exemplo, um eNB fonte ou um CIoT BS fonte) localizado na RAN 2, uma mensagem de Liberação de Conexão RRC para solicitar redirecionamento. Alternativamente, mediante a realização de uma nova seleção de célula, de acordo com a mensagem de Liberação de Conexão RRC para solicitar o redirecio- namento, o UE 1 pode liberar (ou eliminar) informação sobre o tipo de arquitetura de comunicação que foi configurado no (ou aplicado ao) UE 1 em uma célula antes da nova seleção de célula. Nesse caso, a causa da liberação utilizada na mensagem de Liberação de Conexão RRC pode ser configurada para "outros". Alternativamente, uma nova causa (por exemplo, redirectionForCIoT, redirectionForCellUpdate, re- directionRequired, ou cellUpdateRequired) pode ser definida e utilizada como a causa de liberação.
[000206] Depois da mudança de célula do UE 1, o UE 1, a RAN 2 e a CN 3 podem determinar (ou selecionar) um tipo de arquitetura de comunicação a ser utilizado para o UE 1 de acordo com qualquer um dos métodos descritos nas modalidades descritas acima. Alternativamente, depois da mudança de célula, o UE 1 pode realizar a transmissão de dados de acordo com uma forma existente na LTE e LTE-Avançada (isso é, o UE 1 pode voltar para um mecanismo de legado/conven-cional).
[000207] Como descrito acima, nessa modalidade, depois da realização de uma mudança de célula no modo inativo (ou um modo de suspensão) ou modo conectado, o UE 1 libera (ou elimina) a configuração do tipo de arquitetura de comunicação que foi utilizado antes da mudança de célula. É dessa forma possível se impedir uma inconsistência (ou falta de combinação) entre a configuração do tipo de arquitetura de comunicação no UE 1 e na rede depois da mudança de célula. Décima Nona Modalidade
[000208] Um exemplo de configuração de uma rede de comunicação de rádio, de acordo com essa modalidade, é similar a um ilustrado na figura 2. O UE 1 de acordo com essa modalidade pode ser um dispositivo CIoT (por exemplo, NB-IoT ou LTE eMTC), ou pode ser um UE em conformidade com LTE, LTE-Avançada, ou versões modificadas desses padrões. Essa modalidade fornece exemplos da mobilidade de modo inativo em um caso no qual um dos tipos de arquitetura de comunicação descritos acima é aplicado ao UE 1.
[000209] O UE 1, de acordo com essa modalidade, transmite para a RAN 2 ou CN 3, depois da realização de uma nova seleção de célula, um elemento de informação indicando de forma explícita e implícita o tipo de arquitetura de comunicação que foi configurado no (ou aplicado ao) UE 1 desde antes da nova seleção de célula. Especificamente, o UE 1 pode transmitir o elemento de informação quando o UE 1 entra no modo RRC-Conectado pela primeira vez depois da nova seleção de célula.
[000210] As figuras 20 e 21 são diagramas de sequência ilustrando exemplos de procedimentos de comunicação de acordo com essa modalidade. A figura 20 ilustra um caso no qual o primeiro tipo de arquitetura de comunicação é utilizado para o UE 1. Enquanto isso, a figura 21 ilustra um caso no qual o segundo tipo de arquitetura de comunica- ção é utilizado para o UE 1. Nos exemplos ilustrados nas figuras 20 e 21, a RAN 2 inclui uma RAN-1 2A e uma RAN-2 2B. A RAN1-2A corresponde a um nó RAN (por exemplo, CIoT BS ou eNB) antes da mudança de célula (uma nova seleção de célula) e RAN-2 2B corresponde a um nó RAN depois da mudança de célula.
[000211] Com referência à figura 20, na etapa 2001, um tipo de arquitetura de comunicação utilizado para o UE 1 é determinado de acordo com qualquer um dos procedimentos descritos na primeira à décima sétima modalidades e o UE 1 é configurado com o tipo de arquitetura de comunicação determinado. No exemplo ilustrado na figura 20, o UE 1 utiliza o primeiro tipo de arquitetura de comunicação.
[000212] O UE 1 mede uma célula servidora e uma célula vizinha no modo RRC-Inativo (ou outro modo de suspensão). Na etapa 2004, o UE 1 realiza uma nova seleção de célula. Nas etapas 2005 e 2006, o UE 1 a RAN-2 2B realiza um procedimento de estabelecimento de conexão RRC de modo que o UE 1 entre no modo RRC-Conectado pela primeira vez depois da nova seleção de célula. Durante esse procedimento, o UE 1 transmite um elemento de informação (por exemplo, informação de tipo de arco configurado) indicando de forma explícita ou implícita o tipo de arquitetura de comunicação que foi configurado (ou aplicado) no UE 1 visto que antes da nova seleção de célula para a RAN-2 2B. Esse elemento de informação pode ser transmitido, por exemplo, por uma mensagem de Solicitação de Conexão RRC ou uma mensagem de Configuração de Conexão RRC Completada. No exemplo ilustrado na figura 20, o elemento de informação indica o primeiro tipo de arquitetura de comunicação. Permite que a RAN-2 2B reconheça o tipo de arquitetura de comunicação que foi configurado (ou aplicado) no UE 1 desde antes da nova seleção de célula e, dessa forma, a RAN-2 pode realizar as operações correspondentes ao tipo de arquitetura de comunicação com o qual o UE 1 foi configurado.
[000213] Na etapa 2007, o UE 1 realiza uma ou ambas a transmissão de dados UL e a recepção de dados DL utilizando uma mensagem NAS. De forma similar às nona e décima modalidades, o UE 1 pode transmitir uma mensagem NAS contendo dados UL em um SRB 1 utilizando uma mensagem de Configuração RRC Completada ou uma mensagem RRC:Transferência de Informação UL. O UE 1 pode receber uma mensagem NAS contendo dados DL em SRB 1 utilizando uma mensagem RRC:Transferência de Informação DL.
[000214] O procedimento ilustrado na figura 20 pode ser modificado como segue. Por exemplo, a RAN-2 2B pode comunicar com a CN 3 para autenticar ou aprovar o UE 1.
[000215] O UE 1 pode utilizar uma mensagem NAS para transmitir para a CN 3 o elemento de informação (por exemplo, informação de tipo de arco configurado) indicando de forma explícita ou implícita o tipo de arquitetura de comunicação que foi configurado (ou aplicado) no UE 1 desde antes da nova seleção de célula. Nesse caso, a CN 3 pode enviar, para a RAN-2 2B, um elemento de informação indicando o tipo de arquitetura de comunicação que foi configurado (ou aplicado) no UE 1.
[000216] Em vez de transmitir o elemento de informação indicando o tipo de arquitetura de comunicação configurado (ou aplicado) no UE 1, o UE 1 pode transmitir, para a RAN-2 2B, um elemento de informação indicando uma retomada do tipo de arquitetura de comunicação já configurado e um elemento de informação indicando uma célula ou nó RAN antes da nova seleção de célula (por exemplo, um ID de Célula Física (PCI), uma frequência Portadora (EARFCN), ou um ID Global de Célula E-UTRAN (ECGI)). Nesse caso, a RAN-2 2B pode pedir a um nó RAN que gerencie a célula antes da nova seleção de célula sobre o tipo de arquitetura de comunicação que foi configurado (ou apli-cado) no UE 1.
[000217] O UE 1 pode transmitir para a CN 3 o elemento de informação indicando uma retomada do tipo de arquitetura de comunicação já configurado. Nesse caso, a CN 3 pode enviar, para RAN-2 2B, um elemento de informação indicando o tipo de arquitetura de comunicação que foi configurado (ou aplicado) no UE 1.
[000218] A seguir, com referência à figura 21, na etapa 2101, um tipo de arquitetura de comunicação utilizado para UE 1 é determinado de acordo com qualquer um dos procedimentos descritos nas primeira à décima sétima modalidades e o UE 1 é configurado com o tipo de arquitetura de comunicação determinada. No exemplo ilustrado na figura 21, o UE 1 utiliza o segundo tipo de arquitetura de comunicação. Na etapa 2102 ,a RAN-1 2A transmite uma mensagem RRC (por exemplo, uma mensagem de Suspensão de Conexão RRC) para suspender a conexão RRC para o UE 1. Depois de receber a mensagem RRC, o UE 1 transita do modo RRC-Conectado para o modo RRC Inativo (ou outro modo de suspensão) e retém a informação sobre a conexão RRC enquanto está no modo RRC-Inativo (ou outro modo de suspensão) (Etapa 2103). De forma similar, a RAN-1 2A e a CN 3 retêm os contextos relacionados com o UE 1 necessários para uma suspensão da conexão RRC (etapa 2103). O UE 1 e a RAN-1 2A armazenam adicionalmente o tipo de arquitetura de comunicação com o qual o UE 1 foi configurado (isso é, o segundo tipo de arquitetura de comunicação, nesse exemplo) (etapa 2104).
[000219] As etapas 2105 e 2106 são similares às etapas 2004 e 2005 na figura 20. No entanto, na mensagem RRC transmitida na etapa 2106, o elemento de informação (por exemplo, a informação tipo arco configurado), que indica de forma explícita ou implícita o tipo de arquitetura de comunicação que foi configurado (ou aplicado) no UE 1, indica o segundo tipo de arquitetura de comunicação. Adicionalmente, a mensagem RRC transmitida na etapa 2106 inclui um elemento de informação (por exemplo, um PCI ou um ECGI) indicando uma célula ou um nó RAN antes da nova seleção de célula.
[000220] Na etapa 2107, depois do recebimento da mensagem RRC na etapa 2106, a RAN-2 2B solicita um contexto UE a partir da RAN-1 2A antes da nova seleção de célula. Na etapa 2098, a RAN-1 2A envia o contexto UE retido na RAN-1 2A para a RAN-2 2B. Na etapa 2109, a RAN-2 2B se comunica com a CN 3 para retomar a conexão RRC suspensa. Especificamente, a RAN-2 2B pode enviar uma mensagem S1-AP: Contexto UE Ativo para a CN 3 e receber uma mensagem S1- AP:Aviso de Recebimento de Contexto UE Ativo a partir de CN 3. A mensagem S1-AP:Contexto UE Ativo aciona um procedimento para modificar um suporte S1 na CN 3. Esse procedimento inclui, por exemplo, a transmissão de uma mensagem de Solicitação de Modificação de Suporte de uma MME (ou um C-SSN) para um GW e transmissão de uma mensagem de Resposta de Modificação de Suporte de S-GW para a MME (ou C-SSN).
[000221] Na etapa 2110, a RAN-2 2B transmite uma mensagem RRC indicando a finalização da retomada da conexão RRC (por exemplo, uma mensagem de Retomada de Conexão RRC Completada) para o UE 1. Essa mensagem RRC inclui uma informação de segurança AS. Na etapa 2111, o UE 1 transmite dados UL através da RAN-2 2B em um suporte UL e recebe dados DL através da RAN-2 2B em um suporte DL.
[000222] Como descrito acima, nessa modalidade, após a realização de uma nova seleção de célula, o UE 1 transmite para a RAN-2 2B ou CN 3 um elemento de informação (por exemplo, informação de tipo de arco configurado) no (ou aplicado ao) UE 1 desde antes da nova seleção de célula. É, dessa forma, possível se evitar uma inconsistência (ou falta de combinação) entre a configuração do tipo de arquitetura de comunicação no UE 1 e a da rede depois da mudança de célula.
[000223] Um exemplo de configuração de uma rede de comunicação de rádio, de acordo com essa modalidade, é similar a um ilustrado na figura 2. O UE 1, de acordo com essa modalidade, pode ser um dispositivo CIoT (por exemplo, NB-IoT ou LTE eMTC), ou pode ser um UE em conformidade com LTE, LTE-Avançada, ou versões modificadas desses padrões. Essa modalidade fornece exemplos de mobilidade de modo conectado em um caso no qual um dos tipos de arquitetura de comunicação descritos acima é aplicado ao UE 1.
[000224] Nessa modalidade, quando da realização de uma transferência do UE 1, um nó RAN fonte (por exemplo, CIoT BS ou eNB) transmite uma Solicitação de Transferência incluindo um elemento de informação indicando de forma explícita ou implícita indicando um tipo de arquitetura de comunicação que foi configurada no UE 1 (isso é, utilizado para o UE 1) para um nó RAN alvo (por exemplo, CIoT BS ou eNB).
[000225] As figuras 22 e 23 são diagramas de sequência ilustrando exemplos de procedimentos de comunicação de acordo com essa modalidade. A figura 22 ilustra um caso no qual o primeiro tipo de arquitetura de comunicação é utilizado para o UE 1. Enquanto isso, a figura 23 ilustra um caso no qual o segundo tipo de arquitetura de comunicação é utilizado para o UE 1. Nos exemplos ilustrados nas figuras 22 e 23, a RAN 2 inclui uma RAN-1 2A e uma RAN-2 2B. A RAN-1 2A corresponde ao nó RAN fonte (por exemplo, CIoT BS ou eNB) e a RAN-2 2B corresponde ao nó RAN alvo.
[000226] Com referência à figura 22, na etapa 2201, um tipo de arquitetura de comunicação para o UE 1 é determinado de acordo com qualquer um dos procedimentos descritos nas modalidades, da primeira à décima sétima, e o UE 1 é configurado com o tipo de arquitetura de comunicação determinado. No exemplo ilustrado na figura 22, o UE 1 utiliza o primeiro tipo de arquitetura de comunicação. Na etapa 2202, o UE 1 está no modo RRC Conectado. De acordo, na etapa 2202, o UE 1 pode realizar uma ou ambas a transmissão de dados UL e a recepção de dados DL utilizando uma mensagem NAS.
[000227] Na etapa 2203, o UE 1 transmite um relatório de medição indicando um resultado de medição da célula servidora e uma célula vizinha para a RAN-1 2A fonte. Na etapa 2004, a RAN-1 2A fonte determina uma transferência do UE 1 para a RAN-2 2B alvo. Na etapa 2005, a RAN-1 2A fonte envia uma solicitação de transferência para a RAN-2 2B alvo. Essa solicitação de transferência inclui um elemento de informação (por exemplo, uma informação de tipo de arco) indicando um tipo de arquitetura de comunicação utilizado para o UE 1 na RAN-1 2A fonte (isso é, o primeiro tipo de arquitetura de comunicação nesse exemplo).
[000228] Na etapa 2206, depois de receber a solicitação de transferência, a RAN-2 2B alvo envia uma mensagem de resposta para a solicitação de transferência (por exemplo, uma mensagem de Aviso de Recebimento de Solicitação de Transferência) para a RAN-1 2A fonte. Em algumas implementações, essa mensagem de resposta indica se a RAN-2 2B alvo suporta o tipo de arquitetura de comunicação que foi notificado a partir da RAN-1 2A fonte. Alternativamente, a mensagem de resposta indica de forma explícita ou implícita um tipo de arquitetura de comunicação (alterado) a ser utilizado para o UE 1 na RAN-2 2B alvo.
[000229] Na etapa 2207, a RAN-1 2A fonte transmite para o UE 1 uma instrução de transferência incluindo um elemento de informação (por exemplo, informação de tipo de arco) indicando que o tipo de arquitetura de comunicação atual é utilizado continuamente depois da transferência ou indicando o tipo de arquitetura de comunicação (alterado) a ser aplicado ao UE 1 depois da transferência. A instrução de transferência pode ser, por exemplo, uma mensagem de Reconfiguração de Conexão RRC incluindo um IE MobilityControlInfo. No exemplo ilustrado na figura 22, o primeiro tipo de arquitetura de comunicação é utilizado para o UE 1 também na RAN-2 2B alvo.
[000230] Na etapa 2208, o UE 1 realiza um procedimento de acesso aleatório a fim de sincronizar com a célula alvo (isso é, a RAN-2 2B alvo). Na etapa 2209, o UE 1 transmite uma mensagem de Reconfiguração de Conexão RRC Completada incluindo uma confirmação de transferência (por exemplo, Confirmação de Transferência) para a RAN-2 2B alvo. Na etapa 2210, o UE 1 realiza uma ou ambas a transmissão UL e a recepção DL de acordo com o tipo de arquitetura de comunicação indicado a partir da fonte RAN-1 2A na etapa 2207. No exemplo ilustrado na figura 22, o primeiro tipo de arquitetura de comunicação é utilizado para o UE 1 também na RAN-2 2B alvo. De acordo, na etapa 2210, o UE 1 pode realizar uma ou ambas a transmissão de dados UL e a recepção de dados D utilizando uma mensagem NAS.
[000231] O procedimento ilustrado na figura 22 pode ser modificado como segue. Na etapa 2205, a solicitação de transferência pode indicar que o UE 1 foi autorizado a utilizar o primeiro tipo de arquitetura de comunicação.
[000232] A seguir, com referência à figura 23, na etapa 2301 um tipo de arquitetura de comunicação utilizado para o UE 1 é determinado de acordo com qualquer um dos procedimentos descritos nas modalidades, de primeira à décima sétima, e o UE 1 é configurado com o tipo de arquitetura de comunicação determinado. No exemplo ilustrado na figura 23, o UE 1 utiliza o segundo tipo de arquitetura de comunicação. Na etapa 2302, um procedimento de estabelecimento de suporte para o UE 1 é realizado. Na etapa 2303, o UE 1 transmite os dados UL através da RAN-1 2A em um suporte UL e recebe dados DL através da RAN-1 2A em um suporte DL.
[000233] As etapas 2304 a 2310 são similares às etapas 2203-2209 na figura 22. No entanto, no exemplo ilustrado na figura 23, a RAN-2 2B alvo utiliza o segundo tipo de arquitetura de comunicação para o UE 1. Na etapa 2311, a RAN-2 2B alvo se comunica com a CN 3 para alterar uma rota de suportes S1 para o UE 1 como no caso de um procedimento de transferência normal. Por exemplo, a RAN-2 2B alvo envia uma mensagem S1AP: Solicitação de Comutação de Percurso para a CN 3 e recebe uma mensagem S1AP:Aviso de Recebimento de Solicitação de Comutação de Percurso da CN 3.
[000234] Na etapa 2312, o UE 1 transmite os dados UL através da RAN-2 2B alvo em um suporte UL e recebe dados DL através da RAN- 2 2B alvo em um suporte DL.
[000235] Na etapa 2313, o UE 1, a RAN-2 2B alvo e a CN 3 suspendem a conexão RRC.
[000236] Os procedimentos das figuras 22 e 23 podem ser combinados como adequado. Isso é, como já descrito, a RAN-2 2B alvo pode aplicar ao UE 1 um tipo de arquitetura de comunicação diferente do que foi aplicado ao UE 1 na RAN-1 2A fonte. De acordo, na figura 22, quando a mensagem de resposta de transferência (etapa 2206) indica que o segundo tipo de arquitetura de comunicação deve ser utilizado para o UE 1 na RAN-2 2B alvo, etapas 2311 a 2313 ilustradas na figura 23 podem ser realizadas em vez da realização da etapa 2210. O mesmo é verdadeiro para o caso inverso.
[000237] Como descrito acima, nessa modalidade, a RAN-1 2A fonte transmite, para a RAN-2 2B alvo, uma Solicitação de Transferência incluindo um elemento de informação indicando um tipo de arquitetura de comunicação que foi configurado no UE 1 (isso é, utilizado para o UE 1). É, dessa forma, possível se impedir uma inconsistência (ou falta de combinação) entre a configuração do tipo de arquitetura de co-municação no UE 1 e da RAN-2 2B alvo.
[000238] Adicionalmente, nessa modalidade, a RAN-2 2B alvo para a RAN-1 2A fonte uma mensagem de resposta de transferência incluindo um elemento de informação que indica se a RAN-2 2B alvo suporta o tipo de arquitetura de comunicação que foi notificado a partir da RAN-1 2A fonte ou indicando o tipo de arquitetura de comunicação (alterado) a ser utilizado para o UE 1 na RAN-2 2B alvo. Adicionalmente, a RAN-1 2A fonte transmite para o UE 1 uma instrução de transferência incluindo um elemento de informação indicando o tipo de arquitetura de comunicação a ser utilizado para o UE 1 na RAN-2 2B alvo. Permite que a RAN-2 2B alvo utilize, para o UE 1, um tipo de arquitetura de comunicação diferente de um que foi utilizado na RAN-1 2A fonte.
[000239] Um exemplo de configuração de uma rede de comunicação de rádio, de acordo com essa modalidade, é similar a um ilustrado na figura 2. O UE 1, de acordo com essa modalidade pode ser um dispositivo CIoT (por exemplo, NB-IoT ou LTE eMTC), ou pode ser um UE em conformidade com LTE, LTE-Avançada, ou versões modificadas desses padrões. Essa modalidade fornece exemplos de mobilidade de modo conectado em um caso no qual um dos tipos de arquitetura de comunicação descritos acima é aplicado ao UE 1.
[000240] Nessa modalidade, durante um procedimento de transferência de avanço no modo conectado, o UE 1 transmite para a RAN-2 2B alvo um elemento de informação indicando de forma explícita ou implícita um tipo de arquitetura de comunicação que foi configurado no (ou aplicado ao) UE 1 na RAN-1 2A fonte. Especificamente, o UE 1 pode transmitir esse elemento de informação utilizando uma mensagem de novo estabelecimento de Conexão RRC na direção da RAN-2 2B alvo. O procedimento de transferência de avanço pode ser iniciado como RAN-1 2A transmite uma mensagem de "liberação RRC com redirecionamento" para o UE 1. Alternativamente, o procedimento de transferência de avanço pode ser iniciado voluntariamente pelo UE 1 em resposta à expiração de um temporizador de Falha de Link de Rádio (RLF).
[000241] As figuras 24, 25A e 25B são diagramas de sequência ilustrando exemplos de procedimentos de comunicação de acordo com essa modalidade. A figura 24 ilustra um caso no qual o primeiro tipo de arquitetura de comunicação é utilizado para o UE 1. Enquanto isso, as figuras 25A e 25B ilustram um caso no qual o segundo tipo de arquitetura de comunicação é utilizado para o UE 1. Nos exemplos ilustrados na figura 24, 25A e 25B, a RAN 2 inclui uma RAN-1 2A e uma RAN-2 2B. A RAN-1 2A corresponde ao nó RAN fonte (por exemplo, CIoT BS ou eNB) e a RAN-2 2B corresponde ao nó RAN alvo.
[000242] Com referência à figura 24, as etapas 2401 a 2403 são similares às etapas 2201 a 2203 na figura 22. Na etapa 2404, a RAN-1 2A fonte transmite para o UE 1 uma mensagem de liberação RRC indicando um redirecionamento para a RAN-2 2B alvo. Depois do recebimento da mensagem de liberação RRC, o UE 1 realiza uma nova seleção de célula (etapa 2405). Note-se que a etapa 2404 não precisa necessariamente realizada. Especificamente, o UE 1 pode realizar voluntariamente uma nova seleção de célula (etapa 2405) em resposta à expiração do temporizador RLF.
[000243] Na etapa 2406, o UE 1 transmite uma mensagem de solicitação de novo estabelecimento de conexão RRC para a RAN-2 2B alvo. Essa mensagem de solicitação de novo estabelecimento de conexão RRC inclui um elemento de informação sobre um tipo de arquitetura de comunicação (por exemplo, informação de tipo de arco configurado) que indica de forma explícita ou implícita o tipo de arquitetura de comunicação que foi configurado no (ou aplicado ao) UE 1 na RAN-1 2A fonte.
[000244] Na etapa 2407, a RAN-2 2B alvo transmite uma mensagem de novo estabelecimento de conexão RRC para o UE 1. Essa mensagem pode incluir um elemento de informação sobre um tipo de arquitetura de comunicação (por exemplo, informação de tipo de arco) que indica que o tipo de arquitetura de comunicação atual é utilizado continuamente, ou indica de forma explícita ou implícita um tipo de arquitetura de comunicação (alterada) aplicado ao UE 1 na RAN-2 2B alvo.
[000245] No exemplo ilustrado na figura 24, a RAN-2 2B alvo utiliza o primeiro tipo de arquitetura de comunicação para o UE 1. Dessa forma, a etapa 2408 é similar à etapa 2210 na figura 22.
[000246] A seguir, com referência às figuras 25A e 25B, etapas 2501 a 2504 são similares às etapas 2301 a 2304 na figura 23.
[000247] As etapas 2505 a 2508 são similares às etapas 2404 a 2407 na figura 24. No exemplo ilustrado nas figuras 25A e 25B, a RAN-2 2B alvo utiliza o segundo tipo de arquitetura de comunicação para o UE 1. Dessa forma, as etapas 2509 a 2514 são similares às etapas 2107 a 2112 na figura 21.
[000248] A etapa 2515 é similar à etapa 2313 na figura 23.
[000249] O procedimento ilustrado nas figuras 25A e 25B pode ser modificado como segue. A mensagem de liberação de conexão RRC na etapa 2505 pode indicar um ID de Retomada. O ID de Retomada é um identificador que a RAN 2 designa para o UE 1 para uma suspensão RRC. A RAN 2 utiliza o ID de Retomada para associar o UE 1 com o contexto UE armazenado previamente. Em algumas implementações, a RAN-1 2A fonte pode determinar o ID de Retomada e transmite para o UE 1 e a RAN-2 2B alvo. Alternativamente, a RAN-2 2B alvo pode determinar o ID de Retomada e transmite para o UE 1 através da RAN-1 2A fonte.
[000250] Como descrito acima, nessa modalidade, depois da realiza- ção de uma nova seleção de célula relacionada com uma transferência de avanço, o UE 1 transmite para a RAN-2 2B alvo um elemento de informação indicando um tipo de arquitetura de comunicação que foi configurado no (ou aplicado ao) UE 1 na RAN-1 2A fonte (por exemplo, informação de tipo de arco configurado). É, dessa forma possível, se evitar uma inconsistência (ou falta de combinação) entre a configuração do tipo de arquitetura de comunicação no UE 1 e da RAN-2 2B alvo.
[000251] 3GPP está começando a funcionar na padronização para 5G, isso é, 3GPP versão 14, em 2016 para tornar 5G uma realidade comercial em 2020. 5G deve ser realizado pelo aperfeiçoamen- to/evolução contínuos de LTE e LTE-Avançada e um desenvolvimento inovador por uma introdução de uma nova interface de ar 5G (isso é, uma nova Tecnologia de Acesso a Rádio (RAT)). A nova RAT (isso é, nova RAT 5G) suporta, por exemplo, bandas de frequência superiores às bandas de frequência (por exemplo, de 6 GHz ou menos) suportadas por LTE/LTE-Avançada e seu aperfeiçoamento/evolução. Por exemplo, a nova RAT suporta bandas de onda medidas em centímetros (10 GHz ou superior) e bandas de onda medidas em milímetros (30 GHz ou superior).
[000252] Uma frequência mais alta pode fornecer a comunicação de taxa superior. No entanto, devido às suas propriedades de frequência, a cobertura da frequência superior é mais local. Portanto, altas frequências são utilizadas para amplificar a capacidade e as taxas de dados em áreas específicas, enquanto que a cobertura de área ampla e fornecida por frequências de corrente inferior. Isso é, a fim de se garantir a estabilidade da Nova comunicação RAT 5G em bandas de alta frequência, a integração justa ou o trabalho cooperativo entre as frequências alta e baixa (isso é, integração justa ou trabalho cooperativo entre LTE/LTE-Avançada e a Nova RAT 5G) é exigido. Um terminal de rádio de suporte 5G (isso é, Equipamento de Usuário 5G)) é conectado a ambas uma célula de banda de frequência baixa e uma célula de banda de frequência alta (isso é, uma célula LTE/LTE-Avançada e uma nova célula 5G) pela utilização de Agregação de Portador (CA) ou uma Conectividade Dupla (DC), ou uma técnica modificada dos mesmos.
[000253] O termo "LTE" utilizado nessa especificação inclui os aper-feiçoamentos de LTE e LTE-Avançado para 5G para fornecer o trabalho cooperativo justo com a Nova RAT 5G, a menos que indicado o contrário. Tais aperfeiçoamentos de LTE e LTE-Avançada também são referidos como LTE-Avançada Pro, LTE +, ou LTE aperfeiçoada (eL- TE). Adicionalmente, o termo "5G" ou "Novo 5G", nessa especificação é utilizado, por motivos de conveniência, para indicar uma interface aérea (RAT) que é recém-introduzida para os sistemas de comunicação móvel de quinta geração (5G), e nós, células, camadas de protocolo, etc. relacionados com essa interface aérea. Os nomes da interface aérea recém-introduzida (RAT), e nós, células e camadas de protocolo relacionadas com os mesmos serão determinados no futuro como os progressos do trabalho de padronização. Por exemplo, a RAT LTE pode ser referida como RAT Primária (P-RAT ou pRAT) ou Master RAT. Enquanto isso, a nova RAT 5G pode ser referida como a RAT Secundária (S-RAT ou sRAT).
[000254] As primeira a vigésima primeira modalidades descritas acima podem ser aplicadas a uma rede de comunicação de rádio 5G que fornece o trabalho cooperativo justo entre a RAT LTE e a nova RAT 5G. Em algumas implementações, o UE 1, a RAN 2, e a CN 3 podem realizar qualquer um dos procedimentos de anexação descritos na primeira à oitava modalidades na RAT LTE e, então, realizar a transmissão de dados na Nova RAT 5G de acordo com um tipo de arquite-tura de comunicação determinado (ou selecionado) no procedimento de anexação.
[000255] Por exemplo, quando o primeiro tipo de arquitetura de comunicação é utilizado para o UE 1, o UE 1 pode transmitir os dados utilizando uma mensagem de Transferência de Informação UL na célula 5G, em vez da utilização de uma mensagem de Configuração de Conexão RRC Completada na célula LTE, e receber dados utilizando uma mensagem de Transferência de Informação DL na célula 5G. Por exemplo, quando o segundo tipo de arquitetura de comunicação é utilizado para o UE 1, o UE 1, a RAN 2 e a CN 3 podem realizar a suspensão e a retomada de uma conexão RRC na célula 5G. Nesse processo, o UE 1 e a RAN 2 podem ser conectados a ambos um nó de rede núcleo para comunicação na célula LTE e um nó de rede núcleo diferente do utilizado para comunicação na célula LTE.
[000256] Por fim, exemplos de configuração do UE 1, um nó na RAN 2 (por exemplo, CIoT BS e eNB) e um nó na CN 3 (por exemplo, C- SGN e MME), de acordo com as modalidades descritas acima serão descritos. A figura 26 é um diagrama em bloco ilustrando um exemplo de configuração do UE 1. Um transceptor de Frequência de Rádio (RF) 2601 realiza um processamento de sinal de RF analógico para comunicar com a RAN 2. O processamento de sinal de RF analógico realizado pelo transceptor de RF 2601 inclui a conversão ascendente de frequência, uma conversão descendente de frequência, e amplificação. O transceptor de RF 2601 é acoplado a uma antena 2602 e a um processador de banda de base 2603. Isso é, o transceptor de RF 2601 recebe os dados de símbolo modulados (ou dados de símbolo OFDM) 2603, gera um sinal de RF de transmissão e supre o sinal de RF de transmissão gerado para a antena 2602. Adicionalmente, o transceptor de RF 2601 gera um sinal de recepção de banda de base com base no sinal de RF de recepção recebido pela antena 2602 e supre o sinal de recepção de banda de base gerado para o processador de banda de base 2603.
[000257] O processador de banda de base 2603 realiza o processamento de sinal de banda de base digital (isso é, processamento de plano de dados) e o processamento de plano de controle para a comunicação de rádio. O processamento de sinal de banda de base digital inclui (a) compressão/descompressão de dados, (b) segmenta- ção/concatenação de dados, (c) composição/decomposição de um formato de transmissão (isso é, quadro de transmissão), (d) codifica- ção/decodificação de canal, (e) modulação (isso é, mapeamento de símbolo)/demodulação, e (f) geração de dados de símbolo OFDM (isso é, sinal OFDM de banda de base) pela Transformação Fourier Rápida Inversa (IFFT). Por outro lado, o processamento de plano de controle inclui o gerenciamento de comunicação da camada 1 (por exemplo, controle de energia de transmissão), camada 2 (por exemplo, gerenciamento de recurso de rádio e processamento de solicitação de repetição automática híbrida (HARQ)), e camada 3 (por exemplo, sinalização referente à anexação, mobilidade e gerenciamento de chamada).
[000258] No caso de LTE ou LTE-Avançada, por exemplo, o processamento de sinal de banda de base digital realizado pelo processador de banda de base 2603 pode incluir o processamento de sinal da camada de Protocolo de Convergência de Dados em Pacote (PDCP), camada de Controle de Link de Rádio (RLC), camada de Controle de Acesso a Meio (MAC), e camada Física (PHY). Adicionalmente, o processamento de plano de controle realizado pelo processador de banda de base 2603 pode incluir o processamento do protocolo de Extrato de Não Acesso (NAS), o protocolo RRC e o Elemento de Controle MAC (MAC CE).
[000259] O processador de banda de base 2603 pode incluir um processador de modem (por exemplo, Processador de Sinal Digital (DSP)) que realiza o processamento de sinal de banda de base digital e um processador de pilha de protocolo (por exemplo, Unidade de Processamento Central (CPU) ou uma Unidade de Microprocessamen- to (MPU)) que realiza o processamento de plano de controle. Nesse caso, o processador de pilha de protocolo, que realiza o processamento de plano de controle, pode ser integrado a um processador de aplicativo 2604 descrito a seguir.
[000260] O processador de aplicativo 2604 também pode se referido como uma CPU, uma MPU, um microprocessador ou um núcleo processador. O processador de aplicativo 2604 pode incluir uma pluralidade de processadores (núcleos processadores). O processador de aplicativo 2604 carrega um programa de software de sistema (Sistema Operacional (OS)) e vários programas de aplicativo (por exemplo, aplicativo de chamada de voz, navegador de rede, mailer, aplicativo de operação de câmera, e aplicativo de aparelho de música) a partir de uma memória 2606 ou a partir de outra memória (não ilustrada) e executa esses programas, fornecendo, assim, várias funções do UE 1.
[000261] Em algumas implementações, como representado por uma linha tracejada (2605) na figura 26, o processador de banda de base 2603 e o processador de aplicativo 2604 podem ser integrados em um único chip. Em outras palavras, o processador de banda de base 2603 e o processador de aplicativo 2604 podem ser implementados em um único dispositivo do Sistema em Chip (SoC) 2605. Um dispositivo SoC pode ser referido como um sistema de Integração de Grande Escala (LSI) ou um conjunto de chip.
[000262] A memória 2606 é uma memória volátil, uma memória não volátil, ou uma combinação dos mesmos. A memória 2606 pode incluir uma pluralidade de dispositivos de memória que são fisicamente independentes um do outro. A memória volátil é, por exemplo, uma Memória de Acesso Randômico Estática (SRAM), uma RAM Dinâmica (DRAM), ou uma combinação das mesmas. A memória não volátil é, por exemplo, uma máscara da Memória de Leitura Apenas (MROM), uma ROM Eletricamente Programável e Eliminável (EEPROM), uma memória flash, um acionador de disco rígido, ou qualquer combinação dos mesmos. A memória 2606 pode incluir, por exemplo, um dispositivo de memória externa que pode ser acessado pelo processador de banda de base 2603, o processador de aplicativo 2604 e o SoC 2605. A memória 2606 pode incluir um dispositivo de memória interna que é integrado ao processador de banda de base 2603, ao processador de aplicativo 2604 ou ao SoC 2605. Adicionalmente, a memória 2606 pode incluir uma memória em um Cartão de Circuito Integrado Universal (UICC).
[000263] A memória 2606 pode armazenar um ou mais módulos de software (programas de computador) 2607 incluindo instruções e dados para realizar o processamento pelo UE 1 descrito nas modalidades acima. Em algumas implementações, o processador de banda de base 2603 ou o processador de aplicativo 2604 podem carregar um ou mais módulos de software 2607 a partir da memória 2606 e executar os módulos de software carregados, realizando, assim, o processamento do UE 1 descrito nas modalidades acima.
[000264] A figura 27 é um diagrama em bloco ilustrando um exemplo de configuração de um nó na RAN 2 (por exemplo, CIoT BS ou eNB), de acordo com as modalidades descritas acima. Como ilustrado na figura 27, o nó inclui um transceptor de RF 2701, uma interface de rede 2703, um processador 2704 e uma memória 2705. O transceptor de RF 2701 realiza o processamento de sinal de RF analógico para comunicar com o terminal de rádio 1. O transceptor de RF 2701 pode incluir uma pluralidade de transceptores. O transceptor de RF 2701 é conectado a uma antena 2702 e ao processador 2704. O transceptor de RF 2701 recebe dados de símbolos modulados (ou dados de sím- bolos OFDM) a partir do processador 2704, gera um sinal de RF de transmissão, e supre o sinal de RF de transmissão gerado para a antena 2702. Adicionalmente, o transceptor de RF 2701 gera um sinal de recepção de banda de base com base em um sinal de RF de recepção recebido pela antena 2702 e supre esse sinal para o processador 2704.
[000265] A interface de rede 2703 é utilizada para se comunicar com nós de rede (por exemplo, MME, C-SGN e S-GW). A interface de rede 2703 pode incluir, por exemplo, um cartão de interface de rede (NIC) em conformidade com a série IEEE 802.3.
[000266] O processador 2704 realiza o processamento de sinal de banda de base digital (isso é, processamento de plano de dados) e processamento de plano de controle para comunicação de rádio. No caso de LTE ou LTE-Avançada, por exemplo, o processamento de sinal de banda de base digital realizado pelo processador 2704 pode incluir o processamento de sinal da camada PDCP, camada RLC, camada MAC e camada PHY. Adicionalmente, o processamento de plano de controle realizado pelo processador 2704 pode incluir o processamento do protocolo S1, o protocolo RRC e MAC CEs.
[000267] O processador 2704 pode incluir uma pluralidade de processadores. O processador 2704 pode incluir, por exemplo, um processador de modem (por exemplo, DSP) que realiza o processamento de sinal de banda de base digital e um processador de pilha de protocolo (por exemplo, CPU ou MPU) que realiza o processamento de plano de controle.
[000268] A memória 2705 é composta de uma combinação de uma memória volátil e uma memória não volátil. A memória volátil é, por exemplo, uma SRAM, uma DRAM, ou uma combinação das mesmas. A memória não volátil é, por exemplo, uma MROM, uma PROM, uma memória flash, um acionador de disco rígido, ou uma combinação dos mesmos. A memória 2705 pode incluir um armazenador localizado distante do processador 2704. Nesse caso, o processador 2704 pode acessar a memória 2705 através da interface de rede 2703 ou uma interface I/O (não ilustrada).
[000269] A memória 2705 pode armazenar um ou mais módulos de software (programas de computador) 2706 incluindo instruções e dados para realizar o processamento pelo nó na RAN 2 (por exemplo, CIoT BS ou eNB), descrito nas modalidades acima. Em algumas implementações, o processador 2704 pode carregar um ou mais módulos de software 2706 a partir da memória 2705 e executar os módulos de software carregados, realizando, assim, o processamento de qualquer nó na RAN 2 descrito nas modalidades acima.
[000270] A figura 28 é um diagrama em bloco ilustrando um exemplo de configuração de um nó na CN 3 (por exemplo, C-SGN e MME), de acordo com as modalidades descritas acima. Como ilustrado na figura 28, o nó inclui uma interface de rede 2801, um processador 2802 e uma memória 2803. A interface de rede 2801 é utilizada para se comunicar com os nós de rede (por exemplo, C-SGN, MME, HSS, S-GW, P-GW, CIoT BS e eNB). A interface de rede 2801 pode incluir, por exemplo, um cartão de interface de rede (NIC) em conformidade com a série IEEE 802.3.
[000271] O processador 2802 carrega um ou mais módulos de software (programas de computador) 2804 a partir da memória 2803 e executa os módulos de software carregados, realizando, dessa forma, o processamento de qualquer nó na CN 3 (por exemplo, C-SGN ou MME) descrita nas modalidades acima. O processador 2802 pode ser, por exemplo, um microprocessador, uma MPU, ou uma CPU. O processador 2802 pode incluir uma pluralidade de processadores.
[000272] A memória 2803 é composta de uma combinação de memória volátil e uma memória não volátil. A memória 2803 pode incluir um armazenador localizado distante do processador 2802. Nesse caso, o processador 2802 pode acessar a memória 2803 através de uma interface I/O (não ilustrada).
[000273] Como descrito com referência às figuras de 26 a 28, cada um dos processadores incluídos no UE 1, os nós na RAN 2 e os nós na CN 3 nas modalidades acima executa um ou mais programas incluindo um conjunto de instruções para fazer com que um computador realize um algoritmo descrito acima com referência aos desenhos. Esses programas podem ser armazenados em vários tipos de meio legível por computador não transitório e, dessa forma, supridos para os computadores. O meio legível por computador não transitório inclui vários tipos de meio de armazenamento tangível. Exemplos de meio legível por computador não transitório incluem um meio de gravação magnética (tal como um disco flexível, uma fita magnética, e um acio- nador de disco rígido), um meio de gravação magneto-ótico (tal como um disco magneto-ótico), uma Memória de Leitura Apenas de Disco Compacto (CD-ROM), CD-R, CD-R/W e uma memória semicondutora (tal como uma ROM de máscara, uma ROM programável (PROM), uma PROM Eliminável (EPROM), uma ROM flash, e uma Memória de Acesso Randômico (RAM)). Esses programas podem ser supridos para computadores pela utilização de vários tipos de meio legível por computador transitório. Exemplos de meio legível por computador transitório incluem um sinal elétrico, um sinal ótico, e uma onda eletromagnética. O meio legível por computador transitório pode ser utilizado para suprir programas para um computador através de uma linha de comunicação com fio (por exemplo, fios elétricos e fibras óticas) ou uma linha de comunicação sem fio.
[000274] Cada uma das modalidades acima pode ser utilizada individualmente, ou duas ou mais das modalidades podem ser adequada-mente combinadas uma com a outra.
[000275] A RAN 2 descrita nas modalidades acima pode ser uma Rede de Acesso a Rádio tipo Nuvem (C-RAN). A C-RAN também é referida como uma RAN Centralizada. Em outras palavras, os processos e as operações realizados pela RAN 2, ou CIoT BS ou eNB na RAN 2, descritos nas modalidades acima podem ser fornecidos por uma ou uma combinação de uma Unidade Digital (DU) e uma Unidade de Rádio (RU) incluída na arquitetura C-RAN. A DU também é referida como uma Unidade de Banda de Base (BBU). A RU é referida também como um Cabeçote de Rádio Remoto (RRH) ou Equipamento de Rádio Remoto (RRE). Isso é, os processos e as operações realizados pela RAN 2, CIoT BS, ou eNB descritos nas modalidades acima po-dem ser fornecidos por qualquer uma ou mais estações de rádio (nós RAN).
[000276] As modalidades descritas acima podem ser aplicadas a uma ou ambas a comunicação em NB-IoT e comunicação em LTE eMTC. Adicionalmente, as modalidades descritas acima podem ser aplicadas à comunicação dos UEs de acordo com LTE, LTE-Avançada e modificações das mesmas. Adicionalmente, as modalidades descritas acima não estão limitadas a LTE, LTE-Avançada e modificações das mesmas e também podem ser aplicadas a outras redes de comunicação de rádio.
[000277] Adicionalmente, as modalidades descritas acima são meramente exemplos de aplicações de ideias técnicas obtidas pelos inventores. Essas ideias técnicas não estão limitadas às modalidades descritas acima e várias modificações podem ser realizadas.
[000278] Esse pedido é baseado em e reivindica os benefícios da prioridade do pedido de patente japonês No. 2015-256034, depositado em 28 de dezembro de 2015, a descrição do qual é incorporada aqui por referência em sua totalidade. Lista de Sinais de Referência 1 equipamento de usuário (UE) 2 rede de acesso a rádio (RAN) 3 rede núcleo (CN) 4 servidor de aplicativo 5 servidor de assinante doméstico (HSS) 6 circuito de acesso servidor (S-GW) 2603 processador de banda de base 2604 processador de aplicativo 2606 memória 2704 processador 2705 memória 2802 processador 2803 memória
Claims (14)
1. Terminal de rádio (1) que compreende: uma memória (2606); e pelo menos um processador (2603) acoplado à memória (2606); caracterizado pelo fato de que o pelo menos um processador (2603) é configurado para transmitir para uma estação de rádio (2) uma mensagem de configuração de conexão de Controle de Recurso de Rádio (RRC) completada incluindo um elemento de informação de assistência UE indicando qual dentre uma pluralidade de tipos de arquitetura de comunicação para a transmissão de pacotes de dados referentes à Internet Celular das Coisas (CIoT) o terminal de rádio (1) deseja utilizar, o terminal de rádio (1) suporta, ou com qual o terminal de rádio (1) está configurado.
2. Terminal de rádio (1), de acordo com a reivindicação 1, caracterizado pelo fato de que a pluralidade de tipos de arquitetura de comunicação inclui um primeiro tipo de arquitetura de comunicação no qual um pacote de dados é transmitido através de um plano de controle e um segundo tipo de arquitetura de comunicação no qual um pacote de dados é transmitido através de um plano de usuário, e o pelo menos um processador (2603) é configurado para, quando o segundo tipo de arquitetura de comunicação é utilizado para o terminal de rádio (1), receber da estação de rádio (2) uma mensagem RRC incluindo uma configuração de Protocolo de Convergência de Dados em Pacote (PDCP) adicional necessária para o segundo tipo de arquitetura de comunicação.
3. Terminal de rádio (1), de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que a mensagem de configuração de conexão de Controle de Recurso de Rádio (RRC) é enviada sem usar um protocolo de Con- vergência de Dados em Pacote (PDCP), e o elemento de informação de assistência UE é informação de camada (RRC) de Extrato de Acesso (AS).
4. Método em um terminal de rádio (1), caracterizado pelo fato de que compreende a etapa de: transmitir, para uma estação de rádio (2), uma mensagem de configuração de conexão de Controle de Recurso de Rádio (RRC) completada incluindo um elemento de informação de assistência UE indicando qual dentre uma pluralidade de tipos de arquitetura de comunicação para a transmissão de pacotes referente à Internet Celular das Coisas (CIoT) o terminal de rádio (1) deseja utilizar, o terminal de rádio (1) suporta, ou com qual o terminal de rádio (1) está configurado.
5. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que a mensagem de configuração de conexão de Controle de Recurso de Rádio (RRC) é enviada sem usar um protocolo de Convergência de Dados em Pacote (PDCP), e o elemento de informação de assistência UE é informação de camada (RRC) de Extrato de Acesso (AS).
6. Meio legível por computador não transitório armazenando um método para fazer com que um computador realize o método em um terminal de rádio (1), caracterizado pelo fato de que o método compreende a transmissão para uma estação de rádio (2) uma mensagem de configuração de conexão de Controle de Recurso de Rádio (RRC) completada incluindo um elemento de informação de assistência UE indicando qual dentre uma pluralidade de tipos de arquitetura de comunicação para a transmissão de pacotes de dados referente à Internet Celular das Coisas (CIoT) o terminal de rádio (1) deseja utilizar, o terminal de rádio (1) suporta, ou com qual o terminal de rádio (1) é configurado.
7. Meio legível por computador não transitório, de acordo com a reivindicação 6, caracterizado pelo fato de que a mensagem de configuração de conexão de Controle de Recurso de Rádio (RRC) é enviada sem usar um protocolo de Convergência de Dados em Pacote (PDCP), e o elemento de informação de assistência UE é informação de camada (RRC) de Extrato de Acesso (AS).
8. Estação de rádio (2) que compreende: uma memória (2705); e pelo menos um processador (2704) acoplado à memória (2705), em que caracterizado pelo fato de que o pelo menos um processador (2704) é configurado para receber uma mensagem de configuração de conexão de Controle de Recurso de Rádio (RRC) completada a partir de um terminal de rádio (1), e para recuperar, a partir da mensagem de configuração de conexão RRC completada, um elemento de informação de assistência UE indicando qual dentre uma pluralidade de tipos de arquitetura de comunicação para a transmissão de pacotes de dados referentes à Internet Celular das Coisas (CIoT) o terminal de rádio (1) deseja utilizar, o terminal de rádio (1) suporta, ou com qual o terminal de rádio (1) está configurado.
9. Estação de rádio (2), de acordo com a reivindicação 8, caracterizada pelo fato de que o pelo menos um processador (2704) é ainda configurado para determinar, com base no elemento de informação de assistência UE, um tipo de arquitetura de comunicação a ser utilizado para a transmissão de pacotes de dados para o terminal de rádio (1).
10. Estação de rádio (2), de acordo com a reivindicação 9, caracterizada pelo fato de que o pelo menos um processador (2704) é ainda configurado para: selecionar, a partir de uma pluralidade de redes núcleo, uma rede núcleo correspondente ao tipo de arquitetura de comunicação determinado; e transmitir, para a rede núcleo selecionada, uma mensagem de Extrato de Não Acesso (NAS) recuperada a partir da mensagem de configuração de conexão RRC completada.
11. Estação de rádio (2), de acordo com a reivindicação 10, caracterizada pelo fato de que o pelo menos um processador (2704) é configurado para transmitir, para a rede núcleo selecionada, a mensagem NAS inicial e uma mensagem UE inicial incluindo um elemento de informação indicando o tipo de arquitetura de comunicação determinado.
12. Estação de rádio (2), de acordo com a reivindicação 10 ou 11, caracterizada pelo fato de que a pluralidade de tipos de arquitetura de comunicação inclui um primeiro tipo de arquitetura de comunicação, no qual um pacote de dados é transmitido através de um plano de controle, e um segundo tipo de arquitetura de comunicação, no qual um pacote de dados é transmitido através de um plano de usuário, e o pelo menos um processador (2704) é configurado para: quando o primeiro tipo de arquitetura de comunicação é determinado para o terminal de rádio (1), transmitir a mensagem NAS inicial para uma primeira rede núcleo correspondente ao primeiro tipo de arquitetura de comunicação; e quando o segundo tipo de arquitetura de comunicação é determinado para o terminal de rádio (1), transmitir a mensagem NAS inicial para uma segunda rede núcleo correspondendo ao segundo tipo de arquitetura de comunicação.
13. Estação de rádio (2), de acordo com qualquer uma das reivindicações 8 a 12, caracterizada pelo fato de que a pluralidade de tipos de arquitetura de comunicação inclui um primeiro tipo de arquitetura de comunicação, no qual um pacote de dados é transmitido através de um plano de controle, e um segundo tipo de arquitetura de comunicação, no qual um pacote de dados é transmitido através de um plano de usuário; e o pelo menos um processador (2704) ser configurado para, quando o segundo tipo de arquitetura de comunicação é utilizado para o terminal de rádio (1), transmitir para o terminal de rádio (1), em resposta ao recebimento da mensagem de configuração de conexão RRC completada, uma mensagem RRC incluindo uma configuração de Protocolo de Convergência de Dados em Pacote (PDCP) adicional necessária para o segundo tipo de arquitetura de comunicação.
14. Estação de rádio (2), de acordo com qualquer uma das reivindicações 8 a 13, caracterizada pelo fato de que a mensagem de configuração de conexão de Controle de Recurso de Rádio (RRC) é enviada sem usar um protocolo de Convergência de Dados em Pacote (PDCP), e o elemento de informação de assistência UE é informação de camada (RRC) de Extrato de Acesso (AS).
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2015256034 | 2015-12-28 | ||
| JP2015-256034 | 2015-12-28 | ||
| PCT/JP2016/004165 WO2017115452A1 (ja) | 2015-12-28 | 2016-09-13 | 無線端末、無線局、コアネットワークノード、及びこれらの方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| BR112018012185A2 BR112018012185A2 (pt) | 2018-11-27 |
| BR112018012185B1 true BR112018012185B1 (pt) | 2024-03-12 |
Family
ID=59224945
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BR112018012185-1A BR112018012185B1 (pt) | 2015-12-28 | 2016-09-13 | Terminal de rádio, método em um terminal de rádio, meio legível por computador não transitório e estação de rádio |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US11943819B2 (pt) |
| EP (1) | EP3399830B1 (pt) |
| JP (3) | JP6741024B2 (pt) |
| KR (2) | KR102081013B1 (pt) |
| CN (2) | CN114025393A (pt) |
| BR (1) | BR112018012185B1 (pt) |
| RU (3) | RU2733421C2 (pt) |
| WO (1) | WO2017115452A1 (pt) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109863783B (zh) * | 2017-04-28 | 2022-05-31 | Lg 电子株式会社 | 根据edt发送数据的方法 |
| CA3091404A1 (en) * | 2017-06-20 | 2018-12-27 | Zte Corporation | Robust adjustment of access and mobility management functions |
| KR102364897B1 (ko) | 2017-07-21 | 2022-02-17 | 광동 오포 모바일 텔레커뮤니케이션즈 코포레이션 리미티드 | 비활성화 상태 하의 다중 연결 회복 방법 및 그 장치 |
| CN113490289B (zh) * | 2017-09-06 | 2023-11-14 | 北京小米移动软件有限公司 | 下行数据传输方法及装置、用户设备、基站 |
| DK3513617T3 (da) | 2017-11-15 | 2021-08-02 | Ericsson Telefon Ab L M | Håndtering af PDCP under genetablering af forbindelse |
| CN108055660B (zh) * | 2017-12-13 | 2021-03-30 | 青岛海信移动通信技术股份有限公司 | 在网络通道中传输数据的方法和物联网终端 |
| KR102381375B1 (ko) * | 2018-03-30 | 2022-04-01 | 삼성전자주식회사 | 이동통신 시스템에서 Cellular IoT 서비스를 제공하는 방법 및 장치 |
| EP3834587B1 (en) * | 2018-08-10 | 2022-05-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Identifying two tunnels set up in one protocol data unit session |
| CN111356131B (zh) * | 2018-12-20 | 2022-04-29 | 华为技术有限公司 | 通信方法、装置及系统 |
| EP3912394A4 (en) * | 2019-01-16 | 2022-08-24 | Telefonaktiebolaget LM Ericsson (publ.) | METHOD AND APPARATUS FOR SELECTING A DEDICATED CORE NETWORK |
| KR102144293B1 (ko) * | 2019-03-13 | 2020-08-13 | 계명대학교 산학협력단 | 듀얼 플레인 구조를 활용한 고속의 사물인터넷 메시지 처리 방법 및 시스템 |
| CN110267356B (zh) * | 2019-05-16 | 2021-03-30 | 北京邮电大学 | 一种基于5g网络的数字电影发行放映系统 |
| CN116530204A (zh) * | 2020-08-31 | 2023-08-01 | 欧芬诺有限责任公司 | 小数据传输的后续数据信息 |
Family Cites Families (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103155605B (zh) * | 2010-03-23 | 2016-08-17 | 交互数字专利控股公司 | 用于机器类型通信的有效信令 |
| EP2589235B1 (en) * | 2010-06-30 | 2014-05-07 | Fujitsu Limited | Transition mechanism for energy efficient mobile overlay network |
| US9313747B2 (en) * | 2011-07-01 | 2016-04-12 | Intel Corporation | Structured codebook for uniform circular array (UCA) |
| WO2013141921A1 (en) * | 2012-03-19 | 2013-09-26 | Rambus Inc. | High capacity memory systems |
| CN103458386B (zh) * | 2012-05-29 | 2016-12-14 | 华为技术有限公司 | 一种数据传输的方法及装置 |
| WO2014045319A1 (ja) | 2012-09-21 | 2014-03-27 | 富士通株式会社 | 無線通信方法、無線通信システム、無線局および無線端末 |
| EP2959693B1 (en) | 2013-02-21 | 2017-11-22 | Altiostar Networks, Inc. | Systems and methods for coordinating transmission of data packets based on frame type detection in a base station |
| US9350550B2 (en) * | 2013-09-10 | 2016-05-24 | M2M And Iot Technologies, Llc | Power management and security for wireless modules in “machine-to-machine” communications |
| CN103929733A (zh) * | 2014-03-12 | 2014-07-16 | 开曼群岛威睿电通股份有限公司 | 用于物联网的设备能力传输的装置和方法 |
| US9565627B2 (en) * | 2014-04-28 | 2017-02-07 | Aruba Networks, Inc. | Distributed radio management |
| EP3269118B8 (en) * | 2015-03-11 | 2021-03-17 | CommScope, Inc. of North Carolina | Distributed radio access network with adaptive fronthaul |
| US10548000B2 (en) * | 2015-06-11 | 2020-01-28 | Intel IP Corporation | Cellular IoT network architecture |
| US10231089B2 (en) * | 2015-06-23 | 2019-03-12 | Lg Electronics Inc. | Method for managing area of terminal in wireless communication system and apparatus therefor |
| WO2017003235A1 (ko) * | 2015-06-30 | 2017-01-05 | 엘지전자(주) | 무선 통신 시스템에서 그룹 메시지를 전송하기 위한 방법 및 이를 위한 장치 |
| WO2017017931A1 (ja) * | 2015-07-24 | 2017-02-02 | 日本電気株式会社 | 移動通信システム、ｍｍｅ、端末、及び通信方法 |
| WO2017018838A1 (ko) * | 2015-07-28 | 2017-02-02 | 엘지전자(주) | 무선 통신 시스템에서 다중의 위치 영역 관리 방법 및 이를 위한 장치 |
| MX2018001609A (es) * | 2015-08-07 | 2018-05-11 | Sharp Kk | Dispositivo terminal, entidad de gestion de modalidad (mme), metodo de control de comunicacion para dispositivo terminal y metodo de control de comunicacion para entidad de gestion de modalidad (mme). |
| US10270892B2 (en) * | 2015-09-21 | 2019-04-23 | Acer Incorporated | Apparatuses and methods for handling mobile originated (MO) cellular internet of things (CIoT) data |
| KR102045408B1 (ko) * | 2015-11-04 | 2019-11-15 | 엘지전자 주식회사 | 무선 통신 시스템에서 서빙 노드 이전 방법 및 이를 위한 장치 |
| US10298549B2 (en) * | 2015-12-23 | 2019-05-21 | Qualcomm Incorporated | Stateless access stratum security for cellular internet of things |
| US10708973B2 (en) * | 2016-01-12 | 2020-07-07 | Intel Corporation | Cellular internet of things (CIoT) optimizations for narrowband (NB) and non-NB IoT networks |
| US10326689B2 (en) * | 2016-12-08 | 2019-06-18 | At&T Intellectual Property I, L.P. | Method and system for providing alternative communication paths |
| JP6800332B2 (ja) * | 2016-12-23 | 2020-12-16 | 中国移動通信有限公司研究院Ｃｈｉｎａ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｏ．， Ｌｔｄ Ｒｅｓｅａｒｃｈ Ｉｎｓｔｉｔｕｔｅ | フロントホール伝送ネットワーク、データ伝送方法及び装置、コンピュータ記憶媒体 |
-
2016
- 2016-09-13 BR BR112018012185-1A patent/BR112018012185B1/pt active IP Right Grant
- 2016-09-13 KR KR1020187018555A patent/KR102081013B1/ko active IP Right Grant
- 2016-09-13 US US15/779,208 patent/US11943819B2/en active Active
- 2016-09-13 KR KR1020207004535A patent/KR102222789B1/ko active IP Right Grant
- 2016-09-13 RU RU2019127912A patent/RU2733421C2/ru active
- 2016-09-13 EP EP16881433.3A patent/EP3399830B1/en active Active
- 2016-09-13 JP JP2017558841A patent/JP6741024B2/ja active Active
- 2016-09-13 CN CN202111176616.0A patent/CN114025393A/zh active Pending
- 2016-09-13 RU RU2018123306A patent/RU2701703C1/ru active
- 2016-09-13 WO PCT/JP2016/004165 patent/WO2017115452A1/ja active Application Filing
- 2016-09-13 CN CN201680077007.0A patent/CN108476535B/zh active Active
-
2020
- 2020-07-06 JP JP2020116196A patent/JP6969636B2/ja active Active
- 2020-09-23 RU RU2020131293A patent/RU2741946C1/ru active
-
2021
- 2021-10-20 JP JP2021171487A patent/JP7168056B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| WO2017115452A1 (ja) | 2017-07-06 |
| EP3399830B1 (en) | 2022-08-10 |
| CN108476535B (zh) | 2021-10-08 |
| JP6741024B2 (ja) | 2020-08-19 |
| US20210212131A1 (en) | 2021-07-08 |
| CN108476535A (zh) | 2018-08-31 |
| JP6969636B2 (ja) | 2021-11-24 |
| RU2019127912A3 (pt) | 2020-04-15 |
| BR112018012185A2 (pt) | 2018-11-27 |
| JP7168056B2 (ja) | 2022-11-09 |
| RU2701703C1 (ru) | 2019-09-30 |
| CN114025393A (zh) | 2022-02-08 |
| JPWO2017115452A1 (ja) | 2018-10-25 |
| KR20180088879A (ko) | 2018-08-07 |
| KR102222789B1 (ko) | 2021-03-03 |
| JP2022009283A (ja) | 2022-01-14 |
| EP3399830A1 (en) | 2018-11-07 |
| KR20200019789A (ko) | 2020-02-24 |
| US11943819B2 (en) | 2024-03-26 |
| RU2733421C2 (ru) | 2020-10-01 |
| RU2741946C1 (ru) | 2021-02-01 |
| KR102081013B1 (ko) | 2020-02-24 |
| EP3399830A4 (en) | 2019-06-26 |
| RU2019127912A (ru) | 2019-10-29 |
| JP2020171053A (ja) | 2020-10-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6969636B2 (ja) | 無線端末、無線端末における方法、及び無線局 | |
| JP6835102B2 (ja) | 基地局及び無線端末並びにこれらの方法 | |
| JP6658893B2 (ja) | 無線アクセスネットワークノード、無線端末、コアネットワークノード、及びこれらの方法 | |
| US10841302B2 (en) | Method and apparatus for authenticating UE between heterogeneous networks in wireless communication system | |
| ES2901117T3 (es) | Terminal de radio, método y programa para el mismo | |
| JP7168048B2 (ja) | ターゲットｒａｎノード、５ｇコアネットワーク装置、及びこれらの方法 | |
| JP2022159487A (ja) | ターゲット無線アクセスネットワークノード、５ｇコアネットワークノード、及びこれらの方法 | |
| JP7290193B2 (ja) | 無線端末及び無線端末における方法 | |
| KR20170007469A (ko) | 데이터 통신에서의 경량 ota 시그널링 메카니즘을 위한 시스템, 장치, 및 방법 | |
| WO2020204781A1 (en) | Ue, network nodes for handling ue category information | |
| BR122020023536B1 (pt) | Terminal de rádio, estação de rádio, nó de rede núcleo e método nos mesmos |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B06U | Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette] | ||
| B09A | Decision: intention to grant [chapter 9.1 patent gazette] | ||
| B15K | Others concerning applications: alteration of classification |
Free format text: AS CLASSIFICACOES ANTERIORES ERAM: H04W 76/02 , H04W 8/22 , H04W 28/18 Ipc: H04W 8/22 (2009.01), H04W 76/10 (2018.01), H04W 28 |
|
| B16A | Patent or certificate of addition of invention granted [chapter 16.1 patent gazette] |
Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 13/09/2016, OBSERVADAS AS CONDICOES LEGAIS |