ES2901117T3 - Terminal de radio, método y programa para el mismo - Google Patents
Terminal de radio, método y programa para el mismo Download PDFInfo
- Publication number
- ES2901117T3 ES2901117T3 ES16889422T ES16889422T ES2901117T3 ES 2901117 T3 ES2901117 T3 ES 2901117T3 ES 16889422 T ES16889422 T ES 16889422T ES 16889422 T ES16889422 T ES 16889422T ES 2901117 T3 ES2901117 T3 ES 2901117T3
- Authority
- ES
- Spain
- Prior art keywords
- type
- communication
- rrc
- rrc connection
- communication architecture
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W48/00—Access restriction; Network selection; Access point selection
- H04W48/18—Selecting a network or a communication service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/12—Messaging; Mailboxes; Announcements
- H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/20—Manipulation of established connections
-
- 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
- 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
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/08—Access point devices
- H04W88/10—Access point devices adapted for operation in multiple networks, e.g. multi-mode access points
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Un terminal de radio (1) que comprende: una memoria (1106); y al menos un procesador (1103) acoplado a la memoria (1106), en el que al menos un procesador (1103) está configurado para soportar una pluralidad de tipos de arquitecturas de comunicación, la pluralidad de tipos de arquitecturas de comunicación incluye: a) un primer tipo de arquitectura de comunicación en el que un paquete de datos se transmite a través de un plano de control y b) un segundo tipo de arquitectura de comunicación en el que un paquete de datos se transmite a través de un plano de usuario y que implica la suspensión y reanudación de una conexión de Control de Recursos de Radio, RRC, la suspensión de la conexión de RRC incluye retener en el terminal de radio un contexto de una conexión de RRC anterior mientras que el terminal de radio está en un estado inactivo de RRC, la reanudación de conexión de RRC incluye la reutilización del contexto retenido en el momento de una configuración de una conexión de RRC posterior con el fin de que el terminal de radio haga una transición del estado inactivo de RRC a un estado conectado de RRC, y en el que al menos un procesador (1103) está configurado además para, en respuesta a la aparición (S402, S502, S602) de una solicitud de transmisión de datos específicos según el primer tipo de arquitectura de comunicación cuando el terminal de radio ya ha sido configurado (S401, S501, S601) por una red para usar tanto el primer como el segundo tipos de arquitecturas de comunicación y el terminal de radio está adaptado para ejecutar la suspensión (S401, S501, S601) para el segundo tipo de arquitectura de comunicación, transmitir (S403, S503, S603) datos usando el primer tipo de arquitectura de comunicación mientras que se conserva el contexto.
Description
DESCRIPCIÓN
Terminal de radio, método y programa para el mismo
Campo técnico
La presente descripción se refiere a un terminal de radio, un método de un terminal de radio y un programa correspondiente para soportar una pluralidad de tipos de arquitecturas de comunicación para la transmisión de datos.
Antecedentes de la técnica
El Proyecto de Cooperación de 3a Generación (3GPP) ha estado estandarizando Internet de las Cosas Celular (CloT). CloT cubierto por el 3GPP incluye Máquina a Máquina mejorado de Evolución a Largo Plazo (eMTC de LTE) y loT de Banda Estrecha (NB-IoT). Los rasgos característicos de eMTC de LTE y NB-IoT incluyen un consumo de energía de Equipo de Usuario (UE) ultrabajo, un gran número de dispositivos por celda, espectro de banda estrecha y cobertura extendida. En eMTC de LTE (Categoría M), el ancho de banda de Radiofrecuencia (RF) de UE se define como 1,4 MHz. Mientras tanto, en NB-IoT, se supone que las tasas pico de enlace descendente y enlace ascendente son 200 kbps o 144 kbps, y el ancho de banda de RF de UE es de alrededor de 200 kHz (el ancho de banda efectivo es 180 kHz) tanto en el enlace ascendente como en el enlace descendente para una optimización de costes adicional, bajo consumo de energía y extensión de cobertura.
La Bibliografía no de patente 1 describe varias soluciones de arquitecturas de comunicación para la transmisión de datos pequeños poco frecuente en la NB-IoT. Estas soluciones incluyen una arquitectura para la transmisión de datos a través del plano de control (es decir, la Solución 2) y una arquitectura para la transmisión de datos a través del plano de usuario (es decir, la Solución 18) que implica la suspensión y reanudación de una conexión de RRC. En la Bibliografía no de patente 1, el soporte de la solución 2 es obligatorio tanto para el UE como para la red, mientras que el soporte de la solución 18 es opcional tanto para el UE como para la red.
La solución 2 se basa en la arquitectura de Red Central (CN) ligera para CIoT. En la arquitectura de CN ligera, en consideración de los casos de uso típicos de los dispositivos de CIoT, la red central solamente soporta un número limitado de funciones, en comparación con las entidades de CN en la LTE existente (es decir, Entidad de Gestión de Movilidad (MME), Pasarela de Servicio (S-GW) y Pasarela de Red de Paquetes de Datos (P-GW)). La Figura 1 muestra una arquitectura de red para CIoT en un caso sin itinerancia.
El Nodo de Pasarela de Servicio de CIoT (C-SGN) es una nueva entidad de red lógica. El C-SGN es un nodo de CN que tiene tanto el plano de control (CP) como el plano de usuario (UP). El C-SGN proporciona un procedimiento de Gestión de Movilidad (MM) limitada para dispositivos de CIoT, un procedimiento de transmisión de datos pequeños, un procedimiento de seguridad para transmisión de datos pequeños y una terminación de una interfaz SGi para el caso sin itinerancia. La función de P-GW se puede separar del C-SGN. En este caso, se usa una interfaz S5 entre el C-SGN y la P-GW. En un caso de itinerancia, el C-SGN proporciona una interfaz S8.
La interfaz S1 -lite es una versión optimizada de S1-C (S1-MME). La interfaz S1 -lite soporta mensajes de Protocolo de Aplicación S1 (S1AP) y elementos de información (IE) para procedimientos de CIoT, y también soporta procedimientos de seguridad optimizados. Para una transmisión de datos pequeños eficiente, los datos de usuario se entregan a través de la capa de S1AP.
Específicamente, en la transmisión de datos pequeños Originados en Móviles (MO) para el caso sin itinerancia, el UE transmite un mensaje de Estrato Sin Acceso (NAS) de enlace ascendente que transporta un paquete de datos pequeños (por ejemplo, Protocolo de Internet (IP), no IP, servicio de mensajes cortos (SMS)). Este mensaje de NAS de enlace ascendente se entrega al C-SGN a través de la Estación Base de CIoT (BS de CIoT). Este mensaje de NAS de enlace ascendente se transmite en un Portador de Radio de Señalización (SRB). De este modo, no se requiere una configuración de un Portador de Radio de Datos (DRB). Además, se puede omitir la Seguridad de Estrato de Acceso (AS).
El C-SGN descifra el mensaje de NAS de enlace ascendente para obtener el paquete de datos pequeños. El C-SGN reenvía el paquete de datos pequeños según el tipo de datos del paquete de datos pequeños. Para datos pequeños de IP, el C-SGN los envía sobre la interfaz SGi. Para SMS, el C-Sg N los envía a una entidad relacionada con SMS (por ejemplo, Centro de Conmutación de Servicios Móviles de Pasarela de SMS (SMS-GMSC), Centro de Conmutación de Servicios Móviles de Interfuncionamiento de SMS (SMS-IWMSC), encaminador de SMS). Para datos pequeños no de IP, el C-SGN los envía a la Función de Exposición de Capacidad de Servicio (SCEF).
En la transmisión de datos pequeños Terminados en Móvil (MT) para el caso sin itinerancia, el C-SGN transmite un mensaje de NAS de enlace descendente que transporta un paquete de datos pequeños al UE a través de la BS de CIoT. También para la transmisión de paquetes de datos pequeños en el enlace descendente, no se requiere un DRB y se puede omitir la seguridad de AS.
La BS de CIoT mostrada en la Figura 1 es una estación base en la Red de Acceso por Radio de CIoT (RAN de CIoT). Un eNB de LTE configurado para ser conectado al C-SGN se puede usar en lugar de la BS de CIoT en la Figura 1. Este eNB de LTE puede ser un eNB que soporte la eMTC de LTE.
Mientras tanto, la arquitectura según la solución 18 proporciona una transmisión de datos pequeños poco frecuente en el plano de usuario. La arquitectura según la solución 18 tiene el rasgo de reutilizar información obtenida de la conexión de RRC anterior para la configuración de conexión de RRC posterior, reduciendo por ello la señalización requerida para la transición de estado del Control de Recursos de Radio (RRC) de UE.
Específicamente, un UE entra en el modo RRC-Inactivo desde el modo RRC-Conectado y retiene información acerca de la conexión de RRC (por ejemplo, un Contexto de Seguridad de Estrato de Acceso, información relacionada con el portador (incluida información de estado de RoHC) y parámetros L2/1 cuando sea aplicable) mientras que está en modo RRC-Inactivo. De manera similar, un eNB retiene información acerca de la conexión de RRC del UE (por ejemplo, Contexto de Seguridad de Estrato de Acceso, información relacionada con el portador (incluida información de estado de RoHC) y parámetros L2/1 cuando sea aplicable). Además, el eNB y la MME retienen los Contextos de UE de S1AP. Además, el eNB retiene direcciones de túnel de S1-U.
Cuando se vuelve al modo RRC-Conectado, el UE envía una Solicitud de Reanudación de Conexión de RRC al eNB. El eNB restaura un o unos DRB, un contexto de seguridad, una conexión de S1AP y un túnel o túneles de S1-U en base a la información retenida previamente acerca de la conexión de RRC. Además, el eNB informa a la MME de un cambio de estado de UE usando un nuevo mensaje de S1AP (por ejemplo, S1AP: Solicitud de Reanudación de Contexto de UE). La MME devuelve el estado de Gestión de Conexión del Sistema de Paquetes Evolucionado (EPS) (ECM) del UE al estado ECM-Conectada y luego envía un mensaje de Solicitud de Modificar Portador a la S-GW. Como resultado, la S-GW reconoce que el UE está en el estado conectado y, por lo tanto, llega a estar lista para transmitir datos de enlace descendente hacia el UE.
En la solución 18, el UE puede volver a RRC-Conectado y a ECM-Conectada sin transmitir un mensaje de NAS (es decir, Solicitud de Servicio). Además, en comparación con el procedimiento de configuración de conexión de RRC heredado, se pueden eliminar los siguientes mensajes de RRC:
- Configuración de Conexión de RRC Completa;
- Comando de Modo de Seguridad de RRC;
- Modo de Seguridad de RRC Completo;
- Reconfiguración de Conexión de RRC; y
- Reconfiguración de Conexión de RRC Completa.
También se hace referencia a la solución 2 y la solución 18 descritas anteriormente como “Datos sobre NAS (DoNAS)” y “Almacenamiento en caché de contexto de AS”, respectivamente. Alternativamente, también se hace referencia a la solución 2 y la solución 18 como “optimización de EPS de CIoT del Plano de Control” y “optimización de EPS de CIoT del Plano de Usuario”, respectivamente.
En este momento, se supone que la solución 2 no usa la seguridad de Estrato de Acceso (AS) y el PDCP, y que ni la solución 2 ni la solución 18 usan el SRB 2.
En algunas implementaciones, la solución a ser aplicada al UE puede ser seleccionada por la red central (es decir, la MME, el C-SGN) en el procedimiento de conexión para este UE. Alternativamente, en algunas implementaciones, el UE en sí mismo puede seleccionar la solución. La red central o el UE hace una selección inicial de la solución a ser aplicada al UE, y después la red central o el UE cambia la solución seleccionada.
La Bibliografía no de patente 2 describe que el UE puede determinar, durante el procedimiento de conexión, cuál de la arquitectura de la Solución 2 y la arquitectura de la Solución 18 preferiría usar. Además, la Bibliografía no de patente 2 describe que un procedimiento de AS o un procedimiento de NAS puede incluir información para permitir que la red seleccione la solución 2 o la solución 18 para la transmisión de datos.
La Bibliografía no de patente 3 describe que el UE puede incluir una Indicación de “Comportamiento de Red Preferido” en un mensaje de NAS, tal como una Solicitud de Conexión, una Solicitud de Conexión de PDN y una Solicitud de Actualización de Área de Seguimiento (TAU). El Comportamiento de Red Preferido indica una solución que el UE puede soportar o que el UE preferiría usar. Específicamente, el Comportamiento de Red Preferido puede incluir la siguiente información:
- Si se soporta la optimización de EPS de CIoT del Plano de Control;
- Si se soporta la optimización de EPS de CIoT del Plano de Usuario;
- Si se prefiere la optimización de EPS de CIoT del Plano de Control o si se prefiere la optimización de EPS de CIoT del Plano de Usuario;
- Si se soporta la transferencia de datos de S1-U;
- Si se solicita la transferencia de SMS sin Conexión Combinada; y
- Si se soporta Conexión sin Conectividad de PDN.
Lista de referencias
Bibliografía no de patente
Bibliografía no de patente 1: 3GPP TR 23.720 V1.2.0 (2015-11), “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements for Cellular Internet of Things (Release 13)”, noviembre de 2015, XP055488771, páginas 19-25 y 82-90 describe mejoras en la arquitectura celular para soportar dispositivos de IoT de complejidad ultrabaja, con limitación de energía y baja tasa de datos, en el que el dispositivo de IoT soporta tanto la solución de CP (solución 2) como la solución de UP (solución 18).
Bibliografía no de patente 2: 3GPP R2-156645, Qualcomm Incorporated, “NB-IoT SA2 architecture implications”, WG2 # 92 de RAN de TSG del 3GPP, Anaheim, EE.UU., 16-20 de noviembre de 2015.
Bibliografía no de patente 3: 3GPP S2-160448, Alcatel-lucent, Vodafone, Qualcomm, Nokia Networks, “Introduction of attach procedure changes for CloT EPS optimization”, Reunión #113 del WG2 de SA de TSG del 3GPP, St. Kitts, 25-29 de enero de 2016.
Bibliografía no de patente 4: LG Electronics: “Interaction between CP and UP solution” Borrador del 3GPP; S2-153925, 20151116-20151120 16 de noviembre de 2015 (16-11 -2015), XP051014009, páginas 1 a 3 trata sobre cómo interactuar con la solución de CP y la solución de UP cuando tanto el UE como la red soportan la solución de UP.
Compendio de la Invención
Los inventores han estudiado arquitecturas de comunicación para CloT y arquitecturas de comunicación para reducir el consumo de energía de un terminal de radio (UE), y encontraron varios problemas incluyendo los tres problemas descritos en detalle a continuación.
En primer lugar, según las enseñanzas de la Bibliografía no de patente 1 a 3, no está claro qué tipo de evento podría hacer que el UE realice la comunicación de la solución 2 (es decir, transmisión de datos sobre el plano de control (NAS)) cuando el UE ya se ha configurado por la red (por ejemplo, la MME, el C-SGN) para usar la solución 18. En segundo lugar, según las enseñanzas de la Bibliografía no de patente 1 a 3 mencionada anteriormente, no está claro cómo se maneja la información (contexto) acerca de la conexión de RRC retenida en el UE cuando el UE se solicita por una capa más alta para transmitir datos según la solución 2 (es decir, transmisión de datos sobre NAS) mientras que se suspende la conexión de RRC para la solución 18 (es decir, comunicación que implica la suspensión y reanudación de la conexión de RRC). La capa más alta es, por ejemplo, una capa de servicio/aplicaciones, una capa de Subsistema Multimedia de IP (IMS) o una capa de NAS.
En tercer lugar, según las enseñanzas de la Bibliografía no de patente 1 a 3 antes mencionada, no está claro qué tipo de mensaje de RRC se usa para transmitir datos según la solución 2 (es decir, transmisión de datos sobre el plano de control (NAS)) cuando el UE se solicita por la capa más alta para transmitir datos según la solución 2 mientras que se suspende la conexión de RRC para la solución 18. Por ejemplo, supongamos que un mensaje de reanudación de conexión de RRC usado para reanudar la conexión de RRC también se usa para la transmisión de datos según la solución 2. En este caso, el eNB recibe este mensaje de reanudación de conexión de RRC, pero podría fallar al reconocer que este mensaje de reanudación de conexión de RRC contiene un mensaje de NAS que transporta datos.
A la luz de lo anterior, en la presente memoria se describe un aparato, un método y un programa que, cuando un terminal de radio ya se ha configurado por una red (por ejemplo, la MME, el C-SGN) para usar un tipo de arquitectura de comunicación que implica la suspensión y reanudación de una conexión de RRC, facilita la realización de manera eficaz de la comunicación según otro tipo de arquitectura de comunicación que implica la transmisión de datos en un plano de control (NAS).
La presente invención se expone en las reivindicaciones independientes adjuntas. Los rasgos opcionales se presentan en las reivindicaciones dependientes adjuntas. A continuación, se presenta de manera ejemplar cualquier realización o aspecto que no forma parte de la invención reivindicada.
Efectos ventajosos de la Invención
Los ejemplos anteriores pueden proporcionar un aparato, un método y un programa que, cuando un terminal de radio ya se ha configurado por una red (por ejemplo, la MME, el C-SGN) para usar un tipo de arquitectura de comunicación que implica la suspensión y reanudación de una conexión de RRC, facilitar realizar de manera eficaz la comunicación según otro tipo de arquitectura de comunicación que implica la transmisión de datos en un plano de control (NAS).
Breve descripción de los dibujos
La Figura 1 es una vista que muestra un ejemplo de una arquitectura de CloT;
La Figura 2 es una vista que muestra un ejemplo de configuración de una red de radiocomunicación según algunas realizaciones;
La Figura 3 es un diagrama de secuencias que muestra un ejemplo de un procedimiento de comunicación según una primera realización;
La Figura 4 es un diagrama de secuencias que muestra un ejemplo de un procedimiento de comunicación según una segunda realización;
La Figura 5 es un diagrama de secuencias que muestra un ejemplo de un procedimiento de comunicación según una tercera realización.
La Figura 6 es un diagrama de secuencias que muestra un ejemplo de un procedimiento de comunicación según una cuarta realización;
La Figura 7 es un diagrama de secuencias que muestra un ejemplo de un procedimiento de comunicación según una quinta realización.
La Figura 8 es un diagrama de secuencias que muestra un ejemplo de un procedimiento de comunicación según una sexta realización;
La Figura 9 es un diagrama de secuencias que muestra un ejemplo de un procedimiento de comunicación según una séptima realización.
La Figura 10 es un diagrama de secuencias que muestra otro ejemplo del procedimiento de comunicación según la séptima realización;
La Figura 11 es un diagrama de bloques que muestra un ejemplo de configuración de un terminal de radio según algunas realizaciones;
La Figura 12 es un diagrama de bloques que muestra un ejemplo de configuración de una estación base según algunas realizaciones; y
La Figura 13 es un diagrama de bloques que muestra un ejemplo de configuración de un nodo de red central según algunas realizaciones.
Descripción de realizaciones
En lo sucesivo, se describirán en detalle realizaciones específicas con referencia a los dibujos. Los mismos elementos o correspondientes se denotan con los mismos signos en todos los dibujos, y las descripciones repetidas se omitirán según sea necesario por el bien de la claridad.
Las siguientes descripciones en las realizaciones se centran principalmente en redes de radiocomunicación para terminales de CIoT, incluyendo eMTC de LTE y NB-IoT. No obstante, estas realizaciones se pueden aplicar a la comunicación de otros UE en LTE, LTE Avanzada y versiones modificadas de las mismas. Es decir, estas realizaciones se pueden aplicar a redes de radio para comunicación de otros UE relacionados con LTE, LTE Avanzada y versiones modificadas de las mismas. Además, estas realizaciones no se limitan a LTE, LTE Avanzada y versiones modificadas de las mismas, y se pueden aplicar a otras redes de radiocomunicación.
Primera realización
La Figura 2 muestra un ejemplo de configuración de una red de radiocomunicación según algunas realizaciones que incluyen esta realización. En el ejemplo mostrado en la Figura 2, un UE 1 que funciona como un dispositivo de CIoT se comunica con un servidor de aplicaciones 4 a través de una Red de Acceso por Radio (RAN) 2 de CIoT y una Red Central (CN) 3. La RAN 2 soporta una pluralidad de tipos de arquitecturas de comunicación para la transmisión de paquetes de datos con respecto a CIoT. La RAN 2 difunde en una celda, usando, por ejemplo, un Bloque de Información Maestro (MIB) o un Bloque de Información de Sistema (SIB), información que indica explícita o implícitamente la pluralidad de tipos de arquitecturas de comunicación soportados por la RAN 2. El UE 1 soporta estos tipos de arquitecturas de comunicación. La CN 3 soporta estos tipos de arquitecturas de comunicación. La CN 3 puede incluir CN dedicadas (DCN), cada una asociada con uno diferente de los tipos de arquitecturas de comunicación.
El UE 1 puede soportar uno o ambos de eMTC de LTE y NB-IoT. En otras palabras, el UE 1 puede soportar o bien una o bien ambas de la RAT de CIoT (RAT de NB-IoT) y la RAT de LTE (eMTC). La RAN 2 puede incluir o bien uno o bien ambos de una BS de CIoT que soporta la RAT de CIoT (RAT de NB-IoT) y un eNB que soporta la RAT de LTE (eMTC). La CN 3 puede incluir un C-SGN, o una MME y una S-GW, o ambas. La CN 3 puede incluir además otras entidades de red tales como una P-GW, un Servidor Local de Abonado (HSS), una Función de Exposición de Capacidad de Servicio (SCEF) y una Función de Reglas de Política y Tarificación (PCRF).
En algunas implementaciones, la pluralidad de tipos de arquitecturas de comunicación puede incluir un primer y segundo tipos de arquitecturas de comunicación correspondientes, respectivamente, a las soluciones 2 y 18, que se describen en la Bibliografía no de patente 1. Se puede hacer referencia al primer tipo de arquitectura de comunicación como “Datos sobre NAS (DoNAS)” u “Optimización de EPS de CIoT del Plano de Control”. Es decir, en el primer tipo de arquitectura de comunicación, los paquetes de datos de usuario transmitidos o recibidos por el UE 1 se transfieren a través del plano de control (por ejemplo, mensajes de NAS transmitidos entre el UE y la MME/el C-SGN). En el primer tipo de arquitectura de comunicación, la RAN 2 no necesita configurar un DRB para la transmisión de paquetes de datos para el UE 1. Además, con respecto al SRB usado para la transmisión de paquetes de datos, se pueden omitir la seguridad de Estrato de Acceso (AS) (es decir, el cifrado y descifrado de los datos del plano de control y la protección de integridad y la verificación de integridad de los datos del plano de
control) por la RAN 2. En otras palabras, se puede omitir el procesamiento de una capa de Protocolo de Convergencia de Paquetes de Datos (PDCP) para el SRB usado para la transmisión de paquetes de datos. En este caso, los paquetes de datos del UE 1 se cifran y descifran por el UE 1 y la CN 3 (por ejemplo, la MME, el C-SGN) usando claves de seguridad de NAS.
En contraste con esto, se puede hacer referencia al segundo tipo de arquitectura de comunicación como “almacenamiento en caché de contexto de AS” u “optimización de EPS de CIoT del Plano de Usuario”. Es decir, en el segundo tipo de arquitectura de comunicación, los paquetes de datos de usuario transmitidos o recibidos por el UE 1 se transfieren a través del plano de usuario (por ejemplo, un portador de EPS que incluye un DRB y un túnel de protocolo de tunelización del Servicio General de Radio por Paquetes (GPRS) (GTP)), e implica la suspensión y reanudación de una conexión de RRC.
La suspensión de una conexión de RRC incluye retener, en el UE 1 y la RAN 2 (por ejemplo, el eNB, la CIoT-BS), información (o un contexto) de una conexión de RRC anterior mientras que el UE 1 está en un estado inactivo de RRC (específicamente, un nuevo estado de RRC para CIoT (por ejemplo, estado de RRC-Inactivo de CIoT)). Como ya se ha descrito, el contexto retenido en el UE 1 y la RAN 2 incluye, por ejemplo, un Contexto de Seguridad de Estrato de Acceso, información relacionada con el portador (incluida información de estado de RoHC) y parámetros de L2/1 cuando sea aplicable. La RAN 2 puede dar instrucciones al UE 1 para suspender una conexión de RRC usando un mensaje de RRC (por ejemplo, Liberación de Conexión de RRC). Además, la RAN 2 puede transmitir información de identificación de terminal (por ejemplo, ID de Reanudación) usada para reanudar la conexión de RRC, usando este mensaje de RRC.
Además, la suspensión de una conexión de RRC incluye retener, en la RAN 2 (por ejemplo, el eNB, la CIoT-BS) y la CN 3 (por ejemplo, la MME, el C-SGN), una asociación de señalización con respecto al UE 1 entre la RAN 2 y la CN 3 mientras que el UE 1 está en el estado inactivo de RRC (y también en el estado de ECM-INACTIVA). Esta asociación de señalización con respecto al UE 1 es una asociación de S1AP. La RAN 2 y la CN 3 retienen esta asociación de S1AP y los Contextos de UE (por ejemplo, ID de S1AP de UE de eNB e ID de S1AP de UE de MME) asociados con la misma. Además, la suspensión de una conexión de RRC incluye la retención, en la RAN 2 (por ejemplo, el eNB, la CIoT-BS) y la CN 3 (por ejemplo, la S-GW), de un contexto de portador con respecto a un portador de datos entre la RAN 2 y la CN 3 mientras que el UE 1 está en el estado inactivo de RRC (y también en el estado de ECM-INACTIVA). Este portador de datos es un portador de S1-U, y este contexto de portador incluye direcciones de túnel de S1-U (es decir, un identificador de punto final de túnel (TEID) de eNB de S1 y un TEID de S-GW de S1).
La reanudación de una conexión de RRC incluye reutilizar el contexto de conexión de RRC retenido por el UE 1 y la RAN 2 (por ejemplo, el eNB, la CIoT-BS) para una configuración de conexión de RRC posterior con el fin de que el UE 1 haga una transición del estado inactivo de RRC al estado conectado de RRC. Además, la reanudación de una conexión de RRC incluye reutilizar o restaurar la asociación de señalización de S1AP retenida y el contexto de portador junto con una configuración de conexión de RRC posterior para que el UE 1 haga una transición del estado inactivo de RRC al estado conectado de RRC.
Más específicamente, cuando el UE 1 vuelve al modo de RRC-Conectado, el UE 1 transmite una Solicitud de Reanudación de Conexión de RRC a la RAN 2 (por ejemplo, el eNB). La RAN 2 restaura un o unos DRB, un contexto de seguridad, una conexión de S1AP y un túnel o túneles de S1-U en base al contexto retenido. Además, la RAN 2 informa a la CN 3 de un cambio de estado del UE usando un nuevo mensaje de S1AP (por ejemplo, S1AP: Solicitud de Reanudación de Contexto de UE). Un nodo del plano de control (por ejemplo, la MME) en la CN 3 devuelve el estado de ECM del UE 1 al estado ECM-Conectada y transmite un mensaje de Solicitud de Modificar Portador a un nodo del plano de usuario (por ejemplo, la S-GW). Como resultado, el nodo del plano de usuario reconoce que el UE 1 está en el estado conectado y, por lo tanto, llega a estar listo para transmitir datos de enlace descendente hacia el UE 1. Obsérvese que, el mensaje de RRC transmitido por el UE 1 para reanudar la conexión de RRC puede ser una Solicitud de Reanudación de Conexión de RRC. Alternativamente, una Solicitud de Conexión de RRC o una Solicitud de Restablecimiento de Conexión de RRC definida en LTE se puede reutilizar para el procedimiento de reanudación de conexión de RRC. En este último caso, se puede definir un nuevo elemento de información (IE) que indica una solicitud de reanudación de una conexión de RRC, y una Solicitud de Conexión de RRC o una Solicitud de Restablecimiento de Conexión de RRC puede incluir este IE para indicar que es una Solicitud de Reanudación de Conexión de RRC.
En esta realización, el UE 1 está adaptado para ser configurado por la red para usar tanto el primer como el segundo tipos de arquitecturas de comunicación.
La Figura 3 es un diagrama de secuencias que muestra un ejemplo de un procedimiento de comunicación según esta realización. En el procedimiento de la Figura 3, en el Paso 301, el UE 1 se configura por la CN 3 (por ejemplo, la MME, el C-SGN) para usar tanto el primer tipo de arquitectura de comunicación (es decir, la Solución 2) como el segundo tipo de arquitectura de comunicación (es decir, la Solución 18). Por ejemplo, el UE 1 puede incluir el “Comportamiento de Red Preferido” en un mensaje de NAS tal como una Solicitud de Conexión, una Solicitud de Conexión de PDN y una Solicitud de Actualización de Área de Seguimiento (TAU). El Comportamiento de Red
Preferido informa a la CN 3 (por ejemplo, la MME) acerca de cuál del primer y segundo tipos de arquitecturas de comunicación que el UE 1 preferiría usar (o cuál del primer y segundo tipos de arquitecturas de comunicación soporta al UE 1). En consideración del “Comportamiento de Red Preferido”, la CN 3 puede determinar el tipo de arquitectura de comunicación a ser usado (o permitido o configurado) para el UE 1 y puede informar al UE 1 de uno 0 más tipos de arquitecturas de comunicación determinados usando un mensaje de NAS (por ejemplo, Aceptación de Conexión, Aceptación de TAU).
En el Paso 302, el UE 1 determina si se cumple un criterio específico (o preconfigurado). En otras palabras, en el Paso 302, el UE 1 detecta (o determina) la aparición de una solicitud de transmisión de datos específicos. El criterio preconfigurado o la solicitud de transmisión de datos específicos desencadena que el UE 1 transmita datos según el primer tipo de arquitectura de comunicación (es decir, transmisión de datos sobre NAS). En un ejemplo, la solicitud de transmisión de datos específicos es una solicitud de una capa más alta (por ejemplo, capa de servicio/aplicaciones, capa de IMS, capa de NAS) a una capa más baja (por ejemplo, capa de NAS, capa de AS) (por ejemplo, en el caso de Acceso Originado en Móviles (MO)). Alternativamente, la solicitud de transmisión de datos específicos puede ser una solicitud de una capa más baja (por ejemplo, capa de AS) a una capa más alta (por ejemplo, capa de NAS) (por ejemplo, en el caso de búsqueda (Acceso Terminado en Móvil (MT)). Por ejemplo, la capa de NAS del UE 1 puede determinar si la solicitud de transmisión de datos específicos se ha recibido desde la capa más alta (por ejemplo, capa de servicio/aplicaciones, capa de IMS) o la capa de AS. Alternativamente, la capa de AS del UE 1 puede determinar si la solicitud de transmisión de datos específicos se ha recibido desde la capa de NAS.
En respuesta a la aparición de una solicitud de transmisión de datos específicos cuando el UE 1 ya se ha configurado por la CN 3 para usar el primer y segundo tipos de arquitecturas de comunicación, el UE 1 transmite datos usando el primer tipo de arquitectura de comunicación. Específicamente, en el Paso 303, la capa de NAS del UE 1 inicia un procedimiento de DoNAS para transmitir datos en la capa de NAS. En el Paso 304, el UE 1 genera un mensaje de NAS que transporta datos pequeños y transmite un mensaje de RRC (por ejemplo, Configuración de Conexión de RRC Completa, Solicitud de Reanudación de Conexión de RRC, Reanudación de Conexión de RRC Completa) que contiene este mensaje de NAS a la RAN 2 (por ejemplo, la CIoT-BS, el eNB).
En el Paso 305, la RAN 2 recibe el mensaje de RRC y envía el mensaje de NAS recuperado del mensaje de RRC a la CN 3 usando un mensaje de S1AP (por ejemplo, Mensaje de UE Inicial, Solicitud de Reanudación de Contexto de UE) (por ejemplo, el C-SGn , la MME). El mensaje de NAS está incrustado en un elemento de información (IE) de Unidad de Datos de Protocolo (PDU) de NAS de este mensaje de S1AP. La RAN 2 puede seleccionar, de las DCN en la CN 3, una DCN correspondiente al primer tipo de arquitectura de comunicación y enviar el mensaje de S1AP a la DCN seleccionada.
En el Paso 306, la CN 3 (por ejemplo, el C-SGN, la MME) descifra el mensaje de NAS de enlace ascendente enviado desde el UE 1 para obtener los datos pequeños. La CN 3 reenvía los datos pequeños a otro nodo, entidad o red según el tipo de datos de los datos pequeños.
En el ejemplo de la Figura 3, la transmisión de datos específicos puede ser un tipo específico de transmisión de datos pequeños. Por ejemplo, la transmisión de datos específicos puede ser transmisión de datos no IP, transmisión de datos de SMS, transmisión de datos (IP) de solamente un paquete, o transmisión de datos relacionada con un servicio predeterminado. Puede ser preferible para estos tipos de datos que sean transferidos sobre el plano de control, en lugar del plano de usuario, debido a que la cantidad de los mismos es pequeña o no son datos de IP.
Según el ejemplo de la Figura 3, cuando el UE 1 ya se ha configurado por la CN 3 para usar el segundo tipo de arquitectura de comunicación, el UE 1 puede usar el primer tipo de arquitectura de comunicación para la transmisión de tipos específicos de datos que son muy adecuados para la transmisión sobre el plano de control. De este modo, el UE 1 puede realizar de manera eficaz la comunicación del primer tipo de arquitectura de comunicación cuando el UE 1 ya se ha configurado por la CN 3 para usar el segundo tipo de arquitectura de comunicación.
Específicamente, cuando el UE 1 se ha configurado por la CN 3 para usar tanto el primer como el segundo tipos de arquitecturas de comunicación, el UE 1 determina cuál del primer y segundo tipos de arquitecturas de comunicación se ha de usar, dependiendo de si la comunicación solicitada es la transmisión de datos específicos. Esto permite que el UE 1 realice correctamente la selección del tipo de arquitectura de comunicación a ser usado cuando el UE 1 se ha configurado con dos o más tipos de arquitecturas de comunicación.
Segunda realización
En esta realización, un ejemplo de configuración de una red de radiocomunicación es similar al de la Figura 2. El UE 1 según esta realización puede ser un dispositivo de CIoT (por ejemplo, NB-IoT, eMTC de LTE), o puede ser otro UE en LTE, LTE Avanzada o versiones modificadas de las mismas.
La Figura 4 es un diagrama de secuencias que muestra un procedimiento de comunicación según esta realización. De manera similar al procedimiento de la Figura 3, en el procedimiento de la Figura 4, en el Paso 401, el UE 1 se configura por la CN 3 (por ejemplo, la MME, el C-SGN) para usar tanto el primer tipo de arquitectura de
comunicación (es decir, la Solución 2) como el segundo tipo de arquitectura de comunicación (es decir, la Solución 18). Además, en el Paso 401, el UE 1 ejecuta una operación de suspensión para el segundo tipo de arquitectura de comunicación. Es decir, el UE 1 retiene un contexto con respecto a una conexión de RRC anterior mientras que el UE 1 está en el estado inactivo de RRC (por ejemplo, estado inactivo de RRC de CIoT).
En el Paso 402, se desencadena la transmisión de datos según el primer tipo de arquitectura de comunicación. Es decir, el UE 1 detecta (o determina) una aparición de una solicitud de transmisión de datos según el primer tipo de arquitectura de comunicación mientras que el UE 1 está ejecutando la operación de suspensión para el segundo tipo de arquitectura de comunicación. Como se describe en la primera realización, la solicitud de transmisión de datos se envía desde una capa más alta (por ejemplo, capa de servicio/aplicaciones, capa de IMS, capa de NAS) a una capa más baja (por ejemplo, capa de NAS, capa de AS) o se envía desde una capa más baja (por ejemplo, capa de AS) a una capa más alta (por ejemplo, capa de NAS). En el ejemplo de la Figura 4, el UE 1 se desencadena para la transmisión de SMS. Obsérvese que la transmisión de SMS es meramente un ejemplo de transmisión adecuado para el primer tipo de arquitectura de comunicación. Como se describe en la primera realización, en el Paso 402, el UE 1 se puede desencadenar para transmisión de datos no de IP, transmisión de datos (IP) de solamente un paquete, o transmisión de datos relacionada con un servicio predeterminado.
En el Paso 403, en respuesta a la aparición de una solicitud de transmisión de datos según el primer tipo de arquitectura de comunicación (por ejemplo, transmisión de SMS) mientras que el UE 1 está ejecutando la operación de suspensión para el segundo tipo de arquitectura de comunicación, el UE 1 inicia la comunicación según el primer tipo de arquitectura de comunicación (es decir, transmisión de datos sobre NAS) mientras que se retiene el contexto de conexión de RRC anterior. En el ejemplo específico mostrado en la Figura 4, la capa de NAS del UE 1 realiza un procedimiento de Reanudación de Conexión de RRC para reanudar una conexión de RRC (Pasos 404 a 406).
En los pasos 404 a 406, se reanuda la conexión de RRC. Específicamente, en el Paso 404, el UE 1 transmite un mensaje de Solicitud de Reanudación de Conexión de RRC a la RAN 2 (por ejemplo, el eNB, la CIoT-BS). El mensaje de Solicitud de Reanudación de Conexión de RRC contiene un ID de reanudación. Este ID de reanudación es, por ejemplo, una combinación de un Identificador Temporal de Red de Radio Celular (C-RNTI) y un ID de Celda (por ejemplo, un ID de Celda Física (PCI)). En la Figura 4, se omite una representación del procedimiento de acceso aleatorio. El mensaje de Solicitud de Reanudación de Conexión de RRC del Paso 404 se puede transmitir en el tercer mensaje (Msg 3) del procedimiento de acceso aleatorio.
La RAN 2 recibe el mensaje de Solicitud de Reanudación de Conexión de RRC, obtiene el ID de reanudación del mensaje de Solicitud de Reanudación de Conexión de RRC y reanuda la conexión de RRC en base al contexto retenido asociado con este ID de reanudación. En el Paso 405, la RAN 2 transmite un mensaje de Reanudación de Conexión de RRC al UE 1. Este mensaje de Reanudación de Conexión de RRC indica, por ejemplo, qué DRB se reanudan. Este mensaje de Reanudación de Conexión de RRC puede incluir parámetros de L2/L1. El UE 1 reanuda el contexto de seguridad de AS retenido según el mensaje de Reanudación de Conexión de RRC del Paso 405. En el Paso 406, el UE 1 transmite un mensaje de Reanudación de Conexión de RRC Completa a la RAN 2.
El procedimiento de reanudación de conexión de RRC mostrado en los Pasos 404 a 406 es meramente un ejemplo. Por ejemplo, aunque los Pasos 404 a 406 muestran un procedimiento de reanudación que incluye tres pasos (o tres mensajes), el procedimiento de reanudación de conexión de RRC se puede realizar mediante dos pasos (dos mensajes). En este caso, se puede omitir la transmisión del UE 1 a la RAN 2 en el Paso 406. Además, se puede hacer referencia al mensaje de la RAN 2 al UE 1 en el Paso 405 como mensaje de Reanudación de Conexión de RRC Completa. Además, la Solicitud de Reanudación de Conexión de RRC, la Reanudación de Conexión de RRC y la Reanudación de Conexión de RRC Completa en el procedimiento de reanudación de conexión de RRC mostradas en los Pasos 404 a 406 se pueden sustituir por una Solicitud de Conexión de RRC (o Solicitud de Restablecimiento de Conexión de RRC), una Configuración de Conexión de RRC (o Restablecimiento de Conexión de RRC) y una Configuración de Conexión de RRC Completa (o Restablecimiento de Conexión de RRC Completo), respectivamente.
En los Pasos 407 a 409, se reanudan la asociación de S1AP y el portador o portadores de S1-U para el UE 1. En el Paso 407, la RAN 2 informa a la CN 3 (por ejemplo, la MME, el C-SGN) acerca de un cambio de estado del UE 1 usando un nuevo mensaje de S1AP (por ejemplo, S1AP: Solicitud de Reanudación de Contexto de UE). La CN 3 devuelve el estado ECM del UE 1 al estado ECM-Conectada y transmite un mensaje de Solicitud de Modificar Portador a la S/P-GW 6 (paso 408). La S/P-GW 6 luego reconoce que el UE 1 está en el estado conectado y llega a estar lista para transmitir datos de enlace descendente hacia el UE 1. En el Paso 409, la CN 3 envía, a la RAN 2, un mensaje de respuesta (por ejemplo, S1AP: Respuesta de Reanudación de Contexto de UE) que indica la finalización de la reanudación de la asociación de S1AP y portador o portadores de S1-U para el UE 1.
En el Paso 410, la capa de NAS del UE 1 inicia un procedimiento de DoNAS para transmitir datos en la capa de NAS. En el Paso 411, el UE 1 genera un mensaje de NAS que transporta datos pequeños (por ejemplo, datos de SMS) y transmite un mensaje de RRC (por ejemplo, Transferencia de Información de UL) que contiene este mensaje de NAS a la RAN 2 (por ejemplo, el eNB, la CIoT-BS). Como ya se ha descrito, en el momento actual, se supone
que ni la solución 2 ni la solución 18 usarán el SRB 2. De este modo, el mensaje de RRC del Paso 411 se puede transmitir usando el SRB 1 en un Canal de Control Dedicado (DCCH).
En el Paso 412, la RAN 2 recibe el mensaje de RRC y envía el mensaje de NAS recuperado a partir del mensaje de RRC a la CN 3 (por ejemplo, el C-SGN, la MME) usando un mensaje de S1AP (por ejemplo, Transporte de NAS de Enlace Ascendente). El mensaje de NAS está incrustado en un elemento de información (IE) de Unidad de Datos de Protocolo (PDU) de NAS del mensaje de S1AP. La RAN 2 puede seleccionar, de las Dc N en la CN 3, una DCN correspondiente al primer tipo de arquitectura de comunicación y enviar el mensaje de S1AP a la DCN seleccionada.
En el Paso 413, la CN 3 (por ejemplo, la MME, el C-SGN) descifra el mensaje de NAS de enlace ascendente enviado desde el UE 1 para obtener los datos pequeños. La CN 3 reenvía el paquete de datos pequeños a otro nodo, entidad o red, según el tipo de datos de los datos pequeños. En el ejemplo de la Figura 4, la CN 3 envía los datos de SMS obtenidos a una entidad relacionada con SMS (por ejemplo, SMS-GMSC, SMS-IWMSC, encaminador de SMS).
Como se puede entender a partir de la descripción anterior, en el procedimiento de comunicación de la Figura 4, en respuesta a la aparición de una solicitud de transmisión de datos según el primer tipo de arquitectura de comunicación (por ejemplo, transmisión de SMS) mientras que el UE 1 está ejecutando la operación de suspensión para el segundo tipo de arquitectura de comunicación, el UE 1 inicia la comunicación según el primer tipo de arquitectura de comunicación (es decir, transmisión de datos sobre NAS) mientras que se retiene el contexto de conexión de RRC anterior. De este modo, incluso cuando la transmisión de datos sobre NAS ocurre mientras que el UE 1 está ejecutando la operación de suspensión para el segundo tipo de arquitectura de comunicación, el UE está continuando la operación de suspensión para el segundo tipo de arquitectura de comunicación.
En el ejemplo de la Figura 4, con el fin de realizar la comunicación del primer tipo de arquitectura de comunicación, el UE 1 transmite a la RAN 2 los mensajes de RRC (por ejemplo, Solicitud de Reanudación de Conexión de RRC, Reanudación de Conexión de RRC Completa) que se usan para reanudar la conexión de RRC en el procedimiento de reanudación de conexión de RRC (Pasos 404 a 406). El UE 1 puede incluir una indicación de transmisión de DoNAS en uno cualquiera o todos estos mensajes de RRC de enlace ascendente. Además o alternativamente, el UE 1 puede incluir una indicación de transmisión de DoNAS en el mensaje de NAS que transporta datos pequeños (por ejemplo, datos de SMS).
Además o alternativamente, el UE 1 puede incluir información acerca de un volumen del almacenador temporal (es decir, estado del almacenador temporal) en uno cualquiera o todos estos mensajes de RRC de enlace ascendente. La información acerca del volumen del almacenador temporal se define nuevamente para la comunicación para DoNAS, esto es, para transmitir información sobre el plano de control (es decir, el SRB). La información acerca del volumen del almacenador temporal indica un volumen del almacenador temporal con respecto a un portador que aún no está establecido y también indica un volumen del almacenador temporal con respecto a los datos a ser transmitidos en un SRB. Es decir, la información acerca del volumen del almacenador temporal difiere del Informe de Estado del Almacenador Temporal (BSR), que se ha definido en LTE y se ha de transportar por un Elemento de Control de MAC (CE de MAC). De este modo, el mensaje de RRC que contiene la información acerca del volumen del almacenador temporal puede indicar una transmisión de DoNAS.
Además o alternativamente, los recursos de radio (por ejemplo, tiempo, frecuencia, grupo de índices de preámbulo) usados para la transmisión de preámbulo de acceso aleatorio se pueden distinguir por adelantado entre el primer tipo de arquitectura de comunicación y el segundo tipo de arquitectura de comunicación. En este caso, la RAN 2 puede determinar si está destinada a la transmisión de DoNAS, dependiendo de qué recurso de radio se use.
Según estas técnicas, la RAN 2 puede reconocer que el procedimiento de reanudación de conexión de RRC está destinado a DoNAS. Además, la RAN 2 puede informar explícitamente a la CN 3 que el procedimiento de reanudación de conexión de RRC está destinado a la transmisión de DoNAS (por ejemplo, optimización de EPS de CIoT seleccionado). Además o alternativamente, la RAN2 (o el UE 1) puede incluir, en la información de NAS (por ejemplo, PDU de Control de NAS), información que indica explícita o implícitamente que el procedimiento de reanudación de conexión de RRC está destinado a DoNAS (por ejemplo, Comportamiento de Red Preferido). Un método para una indicación implícita puede incluir, por ejemplo, configurar todos los ID de portador (por ejemplo, ID de E-RAB) incluidos en un IE de Lista de E-RAB A Ser Reanudados que indica el portador o portadores a ser reanudados a un valor no válido o 0, borrando el IE de Lista de E-RAB A Ser Reanudados, o incluyendo los ID de E-RAB de todos los portadores establecidos (es decir, suspendidos) en el IE de Lista de E-RAB Que Fallaron Al Reanudar. Esto permite que la CN 3 reconozca que el procedimiento de reanudación de conexión de RRC está destinado a DoNAS. De este modo, por ejemplo, la RAN 2 y la CN 3 pueden operar de manera que no realicen señalización (Pasos 408 y 409) para reanudar el portador o portadores de S1-U que no se requieren para la transmisión de DoNAS.
En algunas implementaciones, el UE 1 puede incluir una causa de establecimiento asociada con DoNAS o una causa de reanudación asociada con DoNAS en la Solicitud de Reanudación de Conexión de RRC (Paso 404). El UE 1 puede incluir la causa de establecimiento asociada con DoNAS o la causa de reanudación asociada con DoNAS
en la Reanudación de Conexión de RRC Completa (Paso 406). La causa de establecimiento o la causa de reanudación se puede definir como “mo-Datos-DoNAS”. Alternativamente, el UE 1 puede incluir información (por ejemplo, bandera de 1 bit) que indica si la comunicación está destinada a DoNAS en el ID de reanudación. De esta forma, la RAN 2 puede reconocer que el procedimiento de reanudación de conexión de RRC (Pasos 404 a 406) se realiza para DoNAS. La RAN 2 puede incluir la causa de establecimiento asociada con DoNAS, la causa de reanudación asociada con DoNAS, o un elemento de información correspondiente a ellos en el mensaje de S1AP del Paso 407. Esto permite que la RAN 2 informe a la CN 3 de que no se requiere la reanudación del portador o portadores de S1-U.
Además, en el procedimiento de la Figura 4, para facilitar la interacción entre la capa de NAS y la capa de AS (por ejemplo, la capa de RRC) en el UE 1, la capa de NAS del UE 1 puede operar de la siguiente manera. Obsérvese que la capa de NAS proporciona gestión de movilidad y gestión de sesión, mientras que la capa de AS proporciona control de recursos de radio (RRC).
En el procedimiento de la Figura 4, la capa de NAS del UE 1 necesita solicitar a la capa de AS que inicie el procedimiento de Reanudación de Conexión de RRC para el segundo tipo de arquitectura de comunicación (es decir, Cambio de Contexto de AS) mientras que se especifica (o desencadena) la ejecución del primer tipo de arquitectura de comunicación (es decir, DoNAS). Con el fin de lograr esto, por ejemplo, cuando se transmiten datos de SMS en DoNAS, la capa de NAS del UE 1 puede generar un mensaje de NAS que transporta estos datos de SMS y proporcionar una solicitud de establecimiento de conexión de RRC a la capa de AS. Esta solicitud de establecimiento de conexión de RRC contiene un tipo de llamada (es decir, SMS de origen) que indica la transmisión de SMS desde un móvil, y una nueva causa de establecimiento para DoNAS (por ejemplo, mo-Datos-DoNAS).
En cambio, cuando se transmiten datos no de IP en DoNAS, la capa de NAS del UE 1 genera un mensaje de NAS que transporta estos datos no de IP y proporcionan una solicitud de establecimiento de conexión de RRC a la capa de AS. Esta solicitud de establecimiento de conexión de RRC contiene un nuevo tipo de llamada (es decir, llamada no de IP de origen) que indica la transmisión de datos no IP desde un móvil y una nueva causa de establecimiento para DoNAS (por ejemplo, mo-Datos-DoNAS).
Según estas operaciones, la capa de AS del UE 1 puede reconocer que el procedimiento de Reanudación de Conexión de RRC para el segundo tipo de arquitectura de comunicación (es decir, Cambio de Contexto de AS) se ejecuta para el primer tipo de arquitectura de comunicación (es decir, DoNAS) en base a la nueva combinación del tipo de llamada y la causa de establecimiento.
Tercera realización
En esta realización, un ejemplo de configuración de una red de radiocomunicación es similar al de la Figura 2. El UE 1 según esta realización puede ser un dispositivo de CIoT (por ejemplo, NB-IoT, eMTC de LTE), o puede ser otro UE en LTE, LTE Avanzada o versiones modificadas de las mismas.
La Figura 5 es un diagrama de secuencias que muestra un procedimiento de comunicación según esta realización. Los Pasos 501 y 502 en la Figura 5 son similares a los Pasos 401 y 402 en la Figura 4, respectivamente. En el Paso 501, el UE 1 se configura por la CN 3 (por ejemplo, la MME, el C-SGN) para usar tanto el primer tipo de arquitectura de comunicación (es decir, la Solución 2) como el segundo tipo de arquitectura de comunicación (es decir, la Solución 18). Además, en el Paso 501, el UE 1 ejecuta una operación de suspensión para el segundo tipo de arquitectura de comunicación.
En el Paso 502, se desencadena la transmisión de datos según el primer tipo de arquitectura de comunicación. Es decir, el UE 1 detecta (o determina) la aparición de una solicitud de transmisión de datos según el primer tipo de arquitectura de comunicación mientras que el UE 1 está ejecutando la operación de suspensión para el segundo tipo de arquitectura de comunicación. Como se describe en la primera realización, la solicitud de transmisión de datos se envía desde una capa más alta (por ejemplo, capa de servicio/aplicaciones, capa de IMS, capa de NAS) a una capa más baja (por ejemplo, capa de NAS, capa de AS), o se envía desde una capa más baja (por ejemplo, capa de AS) a una capa más alta (por ejemplo, capa de NAS). En el ejemplo de la Figura 5, el UE 1 se desencadena para la transmisión de SMS. De manera similar a la descripción del Paso 402, la transmisión de SMS es meramente un ejemplo de transmisión adecuada para el primer tipo de arquitectura de comunicación.
En el Paso 503, en respuesta a la aparición de una solicitud de transmisión de datos según el primer tipo de arquitectura de comunicación (por ejemplo, transmisión de SMS) mientras que el UE 1 está ejecutando la operación de suspensión para el segundo tipo de arquitectura de comunicación, el UE 1 inicia la comunicación según el primer tipo de arquitectura de comunicación (es decir, transmisión de datos sobre NAS) mientras que se retiene el contexto de conexión de RRC anterior. En el ejemplo específico mostrado en la Figura 5, la capa de NAS del UE 1 realiza un procedimiento de Reanudación de Conexión de RRC para reanudar una conexión de RRC y también realiza un procedimiento de transmisión de DoNAS (Pasos 504 a 506). En otras palabras, en el ejemplo de la Figura 5, el UE 1 realiza el procedimiento de transmisión de DoNAS que está integrado (o combinado) con el procedimiento de Reanudación de Conexión de RRC.
En los Pasos 504 a 506, un mensaje de NAS que transporta datos de SMS se transmite desde el UE 1 a la RAN 2 al mismo tiempo que se reanuda la conexión de RRC. En el Paso 504, el UE 1 transmite un mensaje de Solicitud de Reanudación de Conexión de RRC a la RAN 2 (por ejemplo, el eNB, la CIoT-BS). En la Figura 5, se omite una representación del procedimiento de acceso aleatorio. El mensaje de Solicitud de Reanudación de Conexión de RRC del paso 504 se puede transmitir en el tercer mensaje (Msg 3) del procedimiento de acceso aleatorio. En el Paso 505, la RAN 2 reanuda la conexión de RRC y transmite un mensaje de Reanudación de Conexión de RRC al UE 1. En el Paso 506, el UE 1 transmite un mensaje de Reanudación de Conexión de RRC Completa a la RAN 2. El mensaje de Reanudación de Conexión de RRC Completa del Paso 506 contiene el mensaje de NAS que transporta los datos de SMS.
En los Pasos 507 a 510, el mensaje de NAS que transporta los datos de SMS se transmite desde la RAN 2 a la CN 3 al mismo tiempo que se reanudan la asociación de S1AP y el portador o portadores de S1-U para el UE 1. En el Paso 507, la RAN 2 informa a la CN 3 (por ejemplo, la Mm E, el C-SGN) acerca de un cambio de estado del UE 1 usando un nuevo mensaje de S1AP (por ejemplo, S1AP: Solicitud de Reanudación de Contexto de UE). La NAS-PDU en el mensaje de S1AP del Paso 507 contiene el mensaje de NAS que transporta los datos de SMS.
En el Paso 508, la CN 3 (por ejemplo, la MME, el C-SGN) descifra el mensaje de NAS de enlace ascendente enviado desde el UE 1 para obtener los datos pequeños. La CN 3 reenvía el paquete de datos pequeños a otro nodo, entidad o red, según el tipo de datos de los datos pequeños. En el ejemplo de la Figura 5, la CN 3 envía los datos de SMS obtenidos a una entidad relacionada con SMS (por ejemplo, SMS-GMSC, SMS-IWMSC, encaminador de SMS).
Los Pasos 509 y 510 son similares a los Pasos 408 y 409 en la Figura 4, respectivamente. La CN 3 devuelve el estado de ECM del UE 1 al estado ECM-Conectada y transmite un mensaje de Solicitud de Modificar Portador a la S/P-GW 6 (Paso 509). Después de eso, la S/P-GW 6 reconoce que el UE 1 está en el estado conectado y, por lo tanto, llega a estar lista para transmitir datos de enlace descendente hacia el UE 1. En el paso 510, la CN 3 envía, a la RAN 2, un mensaje de respuesta (por ejemplo, S1AP: Respuesta de Reanudación de Contexto de UE) que indica la finalización de la reanudación de la asociación de S1AP y el portador o portadores de S1- U para el UE 1.
Como se puede entender a partir de la descripción anterior, en el procedimiento de comunicación de la Figura 5, en respuesta a una aparición de una solicitud de transmisión de datos según el primer tipo de arquitectura de comunicación (por ejemplo, transmisión de SMS) mientras que el UE 1 está ejecutando la operación de suspensión para el segundo tipo de arquitectura de comunicación, el UE 1 inicia la comunicación según el primer tipo de arquitectura de comunicación (es decir, transmisión de datos sobre NAS) mientras que se retiene el contexto de conexión de RRC anterior. De este modo, de manera similar al ejemplo de la Figura 4, incluso cuando la transmisión de datos sobre NAS ocurre mientras que el UE 1 está ejecutando la operación de suspensión para el segundo tipo de arquitectura de comunicación, el UE 1 está continuando la operación de suspensión para el segundo tipo de arquitectura de comunicación.
Además, en el ejemplo de la Figura 5, el UE 1 realiza el procedimiento de transmisión de DoNAS que está integrado (o combinado) con el procedimiento de Reanudación de Conexión de RRC. De este modo, en el ejemplo de la Figura 5, el número de señalizaciones requeridas para la transmisión de DoNAS se puede reducir en comparación con el ejemplo de la Figura 4.
De manera similar al ejemplo de la Figura 4, el procedimiento de reanudación de conexión de RRC mostrado en los Pasos 504 a 506 es meramente un ejemplo. Por ejemplo, se puede omitir la transmisión desde el UE 1 a la RAN 2 en el Paso 506. En este caso, el UE 1 puede incluir el mensaje de NAS que transporta los datos de SMS en el mensaje de Solicitud de Reanudación de Conexión de RRC del Paso 504. Por ejemplo, la Solicitud de Conexión de RRC (o la Solicitud de Restablecimiento de Conexión de RRC), la Configuración de Conexión de RRC (o el Restablecimiento de Conexión de RRC) y la Configuración de Conexión de RRC Completa (o el Restablecimiento de Conexión de RRC Completo) se pueden reutilizar para el procedimiento de reanudación de conexión de RRC en los Pasos 504 a 506.
Además, de manera similar al ejemplo de la Figura 4, en el ejemplo de la Figura 5, el UE 1 puede incluir una indicación de transmisión de DoNAS en uno cualquiera o todos estos mensajes de RRC de enlace ascendente (Pasos 504 y 506). Además o alternativamente, el UE 1 puede incluir una indicación de transmisión de DoNAS en el mensaje de NAS que transporta datos pequeños (por ejemplo, datos de SMS). Además o alternativamente, el UE 1 puede incluir información acerca de un volumen del almacenador temporal (es decir, el estado del almacenador temporal) en uno cualquiera o todos estos mensajes de RRC de enlace ascendente. Además o alternativamente, los recursos de radio (por ejemplo, tiempo, frecuencia, grupo de índices de preámbulo) usados para transmisión de preámbulo de acceso aleatorio se pueden distinguir por adelantado entre el primer tipo de arquitectura de comunicación y el segundo tipo de arquitectura de comunicación. Según estas técnicas, la RAN 2 o la CN 3, o ambas, pueden reconocer que el procedimiento de reanudación de conexión de RRC está destinado a DoNAS. De este modo, por ejemplo, la RAN 2 y la CN 3 pueden operar de manera que no realicen señalización (Pasos 509 y 510) para reanudar el portador o portadores de S1-U que no se requieren para la transmisión de DoNAS.
Además, de manera similar al ejemplo de la Figura 4, en el ejemplo de la Figura 5, cuando se transmiten datos de SMS en DoNAS, la capa de NAS del UE 1 puede generar un mensaje de NAS que transporta estos datos de SMS y proporcionar una solicitud de establecimiento de conexión de RRC a la capa de AS. Esta solicitud de establecimiento de conexión de RRC contiene un tipo de llamada (es decir, SMS de origen) que indica la transmisión de SMS desde un móvil y una nueva causa de establecimiento para DoNAS (por ejemplo, mo-Datos-DoNAS). Además, cuando se transmiten datos no de IP en DoNAS, la capa de NAS del UE 1 puede generar un mensaje de NAS que transporta estos datos no de IP y proporcionar una solicitud de establecimiento de conexión de RRC a la capa de AS. Esta solicitud de establecimiento de conexión de RRC contiene un nuevo tipo de llamada (es decir, llamada no de IP de origen) que indica la transmisión de datos no de IP desde un móvil, y una nueva causa de establecimiento para DoNAS (por ejemplo, mo-Datos-DoNAS).
Cuarta realización
En esta realización, un ejemplo de configuración de una red de radiocomunicación es similar al de la Figura 2. El UE 1 según esta realización puede ser un dispositivo de CIoT (por ejemplo, NB-IoT, eMTC de LTE), o puede ser otro UE en LTE, LTE Avanzada o versiones modificadas de las mismas.
La Figura 6 es un diagrama de secuencias que muestra un procedimiento de comunicación según esta realización. El procedimiento de la Figura 6 es similar al procedimiento descrito anteriormente de la Figura 5. No obstante, en el procedimiento de la Figura 6, se usa un procedimiento de establecimiento de conexión de RRC (Pasos 604 a 606) para la transmisión de datos de DoNAS, en lugar del procedimiento de reanudación de conexión de RRC (Pasos 504 a 506, en la Figura 5).
Los Pasos 601 y 602 en la Figura 6 son similares a los Pasos 501 y 502 de la Figura 5, respectivamente. En el Paso 601, el UE 1 se configura por la CN 3 (por ejemplo, la MME, el C-SGN) para usar tanto el primer tipo de arquitectura de comunicación (es decir, la Solución 2) como el segundo tipo de arquitectura de comunicación (es decir, la Solución 18). Además, en el Paso 501, el UE 1 ejecuta la operación de suspensión para el segundo tipo de arquitectura de comunicación.
En el paso 602, se desencadena la transmisión de datos según el primer tipo de arquitectura de comunicación. Es decir, el UE 1 detecta (o determina) la aparición de una solicitud de transmisión de datos según el primer tipo de arquitectura de comunicación mientras que el UE 1 está ejecutando la operación de suspensión para el segundo tipo de arquitectura de comunicación. Como se describe en la primera realización, la solicitud de transmisión de datos se envía desde una capa más alta (por ejemplo, capa de servicio/aplicaciones, capa de IMS, capa de NAS) a una capa más baja (por ejemplo, capa de NAS, capa de AS), o se envía desde una capa más baja (por ejemplo, capa de AS) a una capa más alta (por ejemplo, capa de NAS). En el ejemplo de la Figura 6, el UE 1 se desencadena para la transmisión de SMS. De manera similar a la descripción de los Pasos 402 y 502, la transmisión de SMS es meramente un ejemplo de transmisión adecuado para el primer tipo de arquitectura de comunicación.
En el Paso 603, en respuesta a la aparición de una solicitud de transmisión de datos según el primer tipo de arquitectura de comunicación (por ejemplo, transmisión de SMS) mientras que el UE 1 está ejecutando la operación de suspensión para el segundo tipo de arquitectura de comunicación, el UE 1 inicia la comunicación según el primer tipo de arquitectura de comunicación (es decir, transmisión de datos sobre NAS) mientras que se retiene el contexto de conexión de RRC anterior. En el ejemplo mostrado en la Figura 6, la capa de NAS del UE 1 realiza el procedimiento de transmisión de DoNAS que se integra (o combina) con el procedimiento de establecimiento de conexión de RRC (Pasos 604 a 606).
En los Pasos 604 a 606, un mensaje de NAS que transporta los datos de SMS se transmite desde el UE 1 a la RAN 2 al mismo tiempo que se establece la conexión de RRC. En el paso 604, el UE 1 transmite un mensaje de Solicitud de Conexión de RRC a la RAN 2 (por ejemplo, el eNB, la CIoT-BS). En la Figura 6, se omite una representación del procedimiento de acceso aleatorio. El mensaje de solicitud de conexión de RRC del Paso 604 se puede transmitir en el tercer mensaje (Msg 3) del procedimiento de acceso aleatorio. En el Paso 605, la RAN 2 transmite un mensaje de Configuración de Conexión de RRC al UE 1. En el Paso 606, el UE 1 transmite un mensaje de Configuración de Conexión de RRC Completa a la RAN 2. El mensaje de Configuración de Conexión de RRC Completa del Paso 506 contiene el mensaje de NAS que transporta datos de SMS.
En el Paso 607, la RAN 2 envía el mensaje de NAS que transporta los datos de SMS a la CN 3 (por ejemplo, la MME, el C-SGN) usando un mensaje de S1AP (por ejemplo, Mensaje de UE Inicial). La NAS-PDU en el mensaje de S1AP del Paso 607 contiene el mensaje de NAS que transporta los datos de SMS. La RAN 2 puede seleccionar, a partir de las DCN en la CN 3, una DCN correspondiente al primer tipo de arquitectura de comunicación y enviar el mensaje de S1AP a la DCN seleccionada.
En el Paso 608, la CN 3 (por ejemplo, la MME, el C-SGN) descifra el mensaje de NAS de enlace ascendente enviado desde el UE 1 para obtener los datos pequeños. La CN 3 reenvía el paquete de datos pequeños a otro nodo, entidad o red, según el tipo de datos de los datos pequeños. En el ejemplo de la Figura 6, la CN 3 envía los datos de SMS obtenidos a una entidad relacionada con SMS (por ejemplo, SMS-GMSC, SMS-IWMSC, encaminador de SMS).
Como se puede entender a partir de la descripción anterior, en el procedimiento de comunicación de la Figura 6, en respuesta a la aparición de una solicitud de transmisión de datos según el primer tipo de arquitectura de comunicación (por ejemplo, transmisión de SMS) mientras que el UE 1 está ejecutando la operación de suspensión para el segundo tipo de arquitectura de comunicación, el UE 1 inicia la comunicación según el primer tipo de arquitectura de comunicación (es decir, transmisión de datos sobre NAS) mientras que se retiene el contexto de conexión de RRC anterior. De este modo, de manera similar al ejemplo de las Figs. 4 y 5, incluso cuando la transmisión de datos sobre NAS ocurre mientras que el UE 1 está ejecutando la operación de suspensión para el segundo tipo de arquitectura de comunicación, el UE 1 está continuando la operación de suspensión para el segundo tipo de arquitectura de comunicación.
Además, en el ejemplo mostrado en la Figura 6, el UE 1 realiza el procedimiento de transmisión de DoNAS que se integra (o combina) con el procedimiento de establecimiento de conexión de RRC. De este modo, en el ejemplo de la Figura 6, el número de señalizaciones requeridas para la transmisión de DoNAS se puede reducir en comparación con el ejemplo de la Figura 4.
Además, de manera similar al ejemplo de la Figura 4, en el ejemplo de la Figura 6, el UE 1 puede incluir una indicación de transmisión de DoNAS en uno cualquiera o todos estos mensajes de RRC de enlace ascendente (Pasos 604 y 606). Además o alternativamente, el UE 1 puede incluir una indicación de transmisión de DoNAS en el mensaje de NAS que transporta datos pequeños (por ejemplo, datos de SMS). Además o alternativamente, el UE 1 puede incluir información acerca de un volumen del almacenador temporal (es decir, el estado del almacenador temporal) en uno cualquiera o todos estos mensajes de RRC de enlace ascendente. Además o alternativamente, los recursos de radio (por ejemplo, tiempo, frecuencia, grupo de índices de preámbulo) usados para la transmisión de preámbulos de acceso aleatorio se pueden distinguir por adelantado entre el primer tipo de arquitectura de comunicación y el segundo tipo de arquitectura de comunicación. Según estas técnicas, la RAN 2 o la CN 3, o ambas, pueden reconocer que el procedimiento de reanudación de conexión de RRC se destina a DoNAS.
Además, de manera similar al ejemplo de la Figura 4, en el ejemplo de la Figura 6, cuando los datos de SMS se transmiten en DoNAS, la capa de NAS del UE 1 puede generar un mensaje de NAS que transporta estos datos de SMS y proporcionar una solicitud de establecimiento de conexión de RRC a la capa de AS. Esta solicitud de establecimiento de conexión de RRC contiene un tipo de llamada (es decir, SMS de origen) que indica la transmisión de SMS desde un móvil, y una nueva causa de establecimiento para DoNAS (por ejemplo, mo-Datos-DoNAS). Además, cuando se transmiten datos no de IP en DoNAS, la capa de NAS del UE 1 puede generar un mensaje de NAS que transporta estos datos no de IP y proporcionar una solicitud de establecimiento de conexión de RRC a la capa de AS. Esta solicitud de establecimiento de conexión de RRC contiene un nuevo tipo de llamada (es decir, llamada no de IP de origen) que indica la transmisión de datos no de IP desde un móvil, y una nueva causa de establecimiento para DoNAS (por ejemplo, mo-Datos-DoNAS).
La descripción anterior acerca de esta realización muestra un ejemplo en el que, cuando el UE 1 está ejecutando la operación de suspensión para el segundo tipo de arquitectura de comunicación, inicia la comunicación según el primer tipo de arquitectura de comunicación mientras que se retiene el contexto de conexión de RRC anterior. Tras terminar la comunicación según el primer tipo de arquitectura de comunicación, el UE 1 puede hacer una transición al modo RRC-Inactivo de nuevo, y luego reanudar la conexión de RRC usando este contexto de conexión de RRC para transmitir datos según el segundo tipo de arquitectura de comunicación.
Alternativamente, en esta realización, el UE 1 puede liberar (o descartar) el contexto de conexión de RRC anterior cuando se establece la conexión de RRC para transmitir datos según el primer tipo de arquitectura de comunicación.
Quinta realización
En esta realización, un ejemplo de configuración de una red de radiocomunicación es similar al de la Figura 2. El UE 1 según esta realización puede ser un dispositivo de CIoT (por ejemplo, la NB-IoT, la eMTC de LTE), o puede ser otro UE en LTE, LTE Avanzada o versiones modificadas de las mismas.
La Figura 7 es un diagrama de secuencias que muestra un ejemplo de un procedimiento de comunicación según esta realización. El procedimiento de la Figura 7 muestra un ejemplo en el que el UE 1 está configurado por la CN 3 (por ejemplo, la MME, el C-SGN) para usar tanto el primer como el segundo tipos de arquitecturas de comunicación y realiza la transmisión de DoNAS mientras que el UE 1 está en el estado de RRC-Conectado.
En el Paso 701, el UE 1 se configura por la CN 3 (por ejemplo, la MME, el C-SGN) para usar tanto el primer tipo de arquitectura de comunicación (es decir, la Solución 2) como el segundo tipo de arquitectura de comunicación (es decir, la Solución 18). En el Paso 702, cuando el UE 1 está en el estado de RRC_Conectado, se desencadena la transmisión de datos según el primer tipo de arquitectura de comunicación. Es decir, el UE 1 detecta (o determina) la aparición de una solicitud de transmisión de datos según el primer tipo de arquitectura de comunicación mientras que el UE 1 está obedeciendo al segundo tipo de arquitectura de comunicación y está en el estado de RRC_Conectado. Como se describe en la primera realización, la solicitud de transmisión de datos se envía desde una capa más alta (por ejemplo, capa de servicio/aplicaciones, capa de IMS, capa de NAS) a una capa más baja
(por ejemplo, capa de NAS, capa de AS), o se envía desde una capa más baja (por ejemplo, capa de AS) a una capa más alta (por ejemplo, capa de NAS).
En el Paso 703, en respuesta a la aparición de una solicitud de transmisión de datos según el primer tipo de arquitectura de comunicación (por ejemplo, transmisión de SMS) mientras que el UE 1 está obedeciendo al segundo tipo de arquitectura de comunicación y en el estado de RRC_Conectado, la capa de NAS del UE 1 inicia la comunicación según el primer tipo de arquitectura de comunicación (es decir, transmisión de datos sobre NAS). En el Paso 704, en respuesta a una solicitud de la capa de NAS del UE 1, la capa de AS del UE 1 realiza el procedimiento de acceso aleatorio y transmite a la RAN 2 (por ejemplo, el eNB, la CIoT-BS) una solicitud de DoNAS en el tercer mensaje (Msg 3) del procedimiento de acceso aleatorio.
En el Paso 705, la RAN 2 transmite una concesión de enlace ascendente (UL) al UE 1 en respuesta a recibir la solicitud de DoNAS. La concesión de UL indica la asignación de recursos de radio de enlace ascendente para permitir que el UE 1 transmita un mensaje de NAS para DoNAS. En el Paso 706, el UE 1 transmite un mensaje de RRC (por ejemplo, Transferencia de Información de UL) que contiene un mensaje de NAS que transporta datos de SMS a la RAN 2 según la concesión de UL (Paso 706). Como ya se ha descrito, en el momento actual, se supone que ni la solución 2 ni la solución 18 usarán el SRB 2. De este modo, el mensaje de RRC del Paso 706 se puede transmitir usando el SRB 1 en un Canal de Control Dedicado (DCCH).
En el Paso 707, la RAN 2 envía el mensaje de NAS recuperado del mensaje de RRC del Paso 706 a la CN 3 (por ejemplo, el C-SGN, la MME) usando un mensaje de S1AP (por ejemplo, Transporte de NAS de Enlace Ascendente). El mensaje de NAS se incrusta en un elemento de información (IE) de Unidad de Datos de Protocolo (PDU) de NAS de este mensaje de S1AP. La RAN 2 puede seleccionar, de las DCN en la CN 3, una DCN correspondiente al primer tipo de arquitectura de comunicación desde dentro de la CN 3 y enviar el mensaje de S1AP a la DCN seleccionada. En el Paso 708, la CN 3 (por ejemplo, la MME, el C-SGN) descifra el mensaje de NAS de enlace ascendente del UE 1 para obtener los datos pequeños. La CN 3 reenvía el paquete de datos pequeños a otro nodo, entidad o red, según el tipo de datos de los datos pequeños. En el ejemplo de la Figura 7, la CN 3 envía los datos de SMS obtenidos a una entidad relacionada con SMS (por ejemplo, SMS-GMSC, SMS-IWMSC, encaminador de SMS). Como se puede entender a partir de la descripción anterior, en el ejemplo de la Figura 7, cuando el UE 1 se ha configurado por la CN 3 para usar el primer y segundo tipos de arquitecturas de comunicación y está en el estado de RRC_Conectado, el UE 1 puede usar el primer tipo de arquitectura de comunicación para transmitir tipos específicos de datos que son muy adecuados para la transmisión sobre el plano de control.
En algunas implementaciones, la solicitud de DoNAS transmitida en el Paso 704 de la Figura 7 se puede transmitir en un Canal Físico de Control de Enlace Ascendente (PUCCH). La solicitud de DoNAS se puede transportar por un formato de Información de Control de Enlace Ascendente (UCI) recién definido o modificado para la solicitud de DoNAS. Cuando el UE 1 tiene recursos de PUCCH disponibles, el UE 1 puede transmitir la solicitud de DoNAS sobre un PUCCH sin realizar el procedimiento de acceso aleatorio.
En algunas implementaciones, la solicitud de DoNAS transmitida en el Paso 704 de la Figura 7 se puede transmitir usando un mensaje de RRC. Este mensaje de RRC puede indicar la causa de establecimiento asociada con DoNAS. Del mismo modo, el mensaje de RRC (por ejemplo, Transferencia de Información de UL) en el Paso 706 puede indicar la causa de establecimiento asociada con DoNAS.
Sexta realización
En esta realización, un ejemplo de configuración de una red de radiocomunicación es similar al de la Figura 2. El UE 1 según esta realización puede ser un dispositivo de CIoT (por ejemplo, la NB-IoT, la eMTC de LTE), o puede ser otro UE en LTE, LTE Avanzada o versiones modificadas de las mismas.
En esta realización, el UE 1 se configura por la CN 3 para usar cualquiera del primer y segundo tipos de arquitecturas de comunicación y no para usar simultáneamente tanto el primer como el segundo tipos de arquitecturas de comunicación.
La Figura 8 es un diagrama de secuencias que muestra un ejemplo de un procedimiento de comunicación según esta realización. En el procedimiento de la Figura 8, en el Paso 801, el UE 1 se configura por la CN 3 (por ejemplo, la MME, el C-SGN) para usar solamente el segundo tipo de arquitectura de comunicación (es decir, la Solución 18). La CN 3 puede permitir que el UE 1 use el primer tipo de arquitectura de comunicación (es decir, la Solución 2) cuando se cumple un criterio preconfigurado.
En el Paso 802, el UE 1 determina que se cumple el criterio preconfigurado. En otras palabras, en el Paso 802, la capa de NAS del UE 1 determina si se ha recibido una solicitud de transmisión de datos específicos desde una capa más alta (por ejemplo, capa de servicio/aplicaciones, capa de IMS). El criterio preconfigurado o la solicitud de transmisión de datos específicos desencadena que el UE 1 transmita datos según el primer tipo de arquitectura de comunicación (es decir, transmisión de datos sobre NAS).
En respuesta a la aparición de una solicitud de transmisión de datos específicos cuando el UE 1 ya se ha configurado por la CN 3 para usar el segundo tipo de arquitectura de comunicación, el UE 1 conmuta del segundo tipo de arquitectura de comunicación al primer tipo de arquitectura de comunicación y transmite datos usando el primer tipo de arquitectura de comunicación. El procedimiento para la transmisión de datos según el primer tipo de arquitectura de comunicación puede ser similar al procedimiento de transmisión de datos pequeños Originados en Móviles (MO) para la solución 2 (es decir, DoNAS) descrita en la Bibliografía no de patente 1.
Es decir, en el Paso 803, la capa de NAS del UE 1 inicia un procedimiento de DoNAS para transmitir datos en la capa de NAS. En el Paso 804, el UE 1 genera un mensaje de NAS que transporta datos pequeños y transmite un mensaje de RRC (por ejemplo, Configuración de Conexión de RRC Completa, Transferencia de Información de UL) que contiene este mensaje de NAS a la RAN 2 (por ejemplo, la CIoT-BS, el eNB).
En el Paso 805, la RAN 2 recibe el mensaje de RRC y envía el mensaje de NAS recuperado del mensaje de RRC a la CN 3 (por ejemplo, el C-SGN, la MME) usando un mensaje de S1AP (por ejemplo, Mensaje de UE Inicial, Transporte de NAS de Enlace Ascendente). El mensaje de NAS está incrustado en un elemento de información (IE) de Unidad de Datos de Protocolo (PDU) de NAS de este mensaje de S1AP. La RAN 2 puede seleccionar, de las DCN en la CN 3, una DCN correspondiente al primer tipo de arquitectura de comunicación y enviar el mensaje de S1AP a la DCN seleccionada.
En el Paso 806, la CN 3 (por ejemplo, el C-SGN, la MME) descifra el mensaje de NAS de enlace ascendente enviado desde el UE 1 para obtener los datos pequeños. La CN 3 reenvía los datos pequeños a otro nodo, entidad o red, según el tipo de datos de los datos pequeños.
En el ejemplo de la Figura 8, la transmisión de datos específicos puede ser similar a la del ejemplo de la Figura 3 descrita en la primera realización. Por ejemplo, la transmisión de datos específicos puede ser transmisión de datos no de IP, transmisión de datos de SMS, transmisión de datos (IP) de solamente un paquete o transmisión de datos relacionada con un servicio predeterminado.
Según el ejemplo de Figura 8, cuando el UE 1 ya se ha configurado por la CN 3 para usar el segundo tipo de arquitectura de comunicación, el UE 1 puede usar el primer tipo de arquitectura de comunicación para transmitir tipos específicos de datos que son muy adecuados para la transmisión sobre el plano de control. De este modo, el UE 1 puede realizar de manera eficaz una comunicación según el primer tipo de arquitectura de comunicación cuando el UE 1 ya se ha configurado por la CN 3 para usar el segundo tipo de arquitectura de comunicación.
Específicamente, en respuesta a la aparición de una solicitud de transmisión de datos específicos cuando el UE 1 ya se ha configurado por la CN 3 para usar solamente el segundo tipo de arquitectura de comunicación, el UE 1 conmuta del segundo tipo de arquitectura de comunicación al primer tipo de arquitectura de comunicación. Es decir, el UE 1 se configura solamente con uno del primer y segundo tipos de arquitecturas de comunicación y, de este modo, no necesita soportar una configuración simultánea de estas dos soluciones. Esto simplifica la configuración del UE 1. Tal configuración es particularmente efectiva para una NB-CIoT que requiere optimización de costes y bajo consumo de energía.
Séptima realización
En esta realización, un ejemplo de configuración de una red de radiocomunicación es similar al de la Figura 2. El UE 1 según esta realización puede ser un dispositivo de CIoT (por ejemplo, la NB-IoT, la eMTC de LTE), o puede ser otro UE en LTE, LTE Avanzada o versiones modificadas de las mismas.
La Figura 9 es un diagrama de secuencias que muestra un ejemplo de un procedimiento de comunicación según esta realización. De manera similar al procedimiento de la Figura 8, en el procedimiento de la Figura 9, en el Paso 901, el UE 1 se configura por la CN 3 (por ejemplo, la MME, el C-SGN) para usar solamente el segundo tipo de arquitectura de comunicación (es decir, la Solución 18). La CN 3 puede permitir que el UE 1 use el primer tipo de arquitectura de comunicación (es decir, la Solución 2) cuando se cumple un criterio específico. En el Paso 901, el UE 1 realiza una operación de suspensión para el segundo tipo de arquitectura de comunicación. Específicamente, el UE 1 retiene un contexto con respecto a una conexión de RRC anterior mientras está en el estado inactivo de RRC (por ejemplo, el estado inactivo de RRC de CIoT).
En el Paso 902, se desencadena la transmisión de datos según el primer tipo de arquitectura de comunicación. Es decir, el UE 1 detecta (o determina) la aparición de una solicitud de transmisión de datos según el primer tipo de arquitectura de comunicación mientras que el UE 1 está ejecutando la operación de suspensión para el segundo tipo de arquitectura de comunicación. Como se describe en la primera realización, la solicitud de transmisión de datos se envía desde una capa más alta (por ejemplo, capa de servicio/aplicaciones, capa de IMS, capa de NAS) a una capa más baja (por ejemplo, capa de NAS, capa de AS), o se envía desde una capa más baja (por ejemplo, capa de AS) a una capa más alta (por ejemplo, capa de NAS). En el ejemplo de la Figura 9, el UE 1 se desencadena para la transmisión de SMS. Obsérvese que la transmisión de SMS es meramente un ejemplo de transmisión adecuada para el primer tipo de arquitectura de comunicación. Como se describe en la primera realización, en el Paso 902, el
UE 1 se puede desencadenar para la transmisión de datos no de IP, transmisión de datos (IP) de solamente un paquete, o transmisión de datos relacionada con un servicio predeterminado.
En el Paso 903, en respuesta a la aparición de una solicitud de transmisión de datos según el primer tipo de arquitectura de comunicación (por ejemplo, transmisión de SMS) mientras que el UE 1 está ejecutando la operación de suspensión para el segundo tipo de arquitectura de comunicación, el UE 1 conmuta del segundo tipo de arquitectura de comunicación al primer tipo de arquitectura de comunicación e inicia la comunicación según el primer tipo de arquitectura de comunicación (es decir, transmisión de datos sobre NAS). El procedimiento para la transmisión de datos según el primer tipo de arquitectura de comunicación puede ser similar al procedimiento de transmisión de datos pequeños Originados en Móviles (MO) para la solución 2 (es decir, DoNAS) descrito en la Bibliografía no de patente 1.
Es decir, en los Pasos 904 a 906, el UE 1 ejecuta un procedimiento de establecimiento de conexión de RRC. En los pasos 904 a 906, se transmite un mensaje de NAS que transporta datos de SMS desde el UE 1 a la RAN 2 al mismo tiempo que se establece la conexión de RRC. En el paso 904, el UE 1 transmite un mensaje de Solicitud de Conexión de RRC a la RAN 2 (por ejemplo, el eNB, la CIoT-BS). En la Figura 9, se omite una representación del procedimiento de acceso aleatorio. El mensaje de Solicitud de Conexión de RRC del Paso 904 se puede transmitir en el tercer mensaje (Msg 3) del procedimiento de acceso aleatorio. En el Paso 905, la RAN 2 transmite un mensaje de Configuración de Conexión de RRC al UE 1. En el Paso 906, el UE 1 transmite un mensaje de Configuración de Conexión de RRC Completa a la RAN 2. El mensaje de Configuración de Conexión de RRC Completa del Paso 906 contiene el mensaje de NAS que transporta los datos de SMS.
En el Paso 907, la RAN 2 envía el mensaje de NAS que transporta los datos de SMS a la CN 3 (por ejemplo, la MME, el C-SGN) usando un mensaje de S1AP (por ejemplo, Mensaje de UE Inicial). La NAS-PDU en el mensaje de S1AP del Paso 907 contiene el mensaje de NAS que transporta los datos de SMS. La RAN 2 puede seleccionar, de las DCN en la CN 3, una DCN correspondiente al primer tipo de arquitectura de comunicación y enviar el mensaje de S1AP a la DCN seleccionada.
En el Paso 908, la CN 3 (por ejemplo, la MME, el C-SGN) descifra el mensaje de NAS de enlace ascendente enviado desde el UE 1 para obtener los datos pequeños. La CN 3 reenvía el paquete de datos pequeños a otro nodo, entidad o red, según el tipo de datos de los datos pequeños. En el ejemplo de la Figura 9, la CN 3 envía los datos de SMS obtenidos a una entidad relacionada con SMS (por ejemplo, SMS-GMSC, SMS-IWMSC, encaminador de SMS).
En algunas implementaciones, cuando el UE 1 inicia la transmisión de datos según el primer tipo de arquitectura de comunicación (Paso 903), puede eliminar o liberar el contexto de conexión de RRC anterior retenido para la operación de suspensión para el segundo tipo de arquitectura de comunicación. El área de memoria en la que se ha almacenado este contexto de conexión de RRC se puede reutilizar para almacenar un contexto de conexión de RRC para la comunicación según el primer tipo de arquitectura de comunicación. En otras palabras, el contexto de conexión de RRC anterior para la operación de suspensión para el segundo tipo de arquitectura de comunicación se puede sobrescribir (o actualizar) por un nuevo contexto de conexión de RRC para la comunicación según el primer tipo de arquitectura de comunicación. Tal configuración y operación puede reducir la capacidad de memoria que debería tener el UE 1, lo cual es particularmente efectiva para una NB-CIoT que requiere optimización de costes y bajo consumo de energía.
Cuando el contexto de conexión de RRC anterior retenido en el UE 1 para la operación de suspensión para el segundo tipo de arquitectura de comunicación se elimina o se libera, el UE 1 puede informar a la RAN 2, o a la CN 3, o a ambas acerca de esta eliminación o liberación. Específicamente, en el procedimiento de control (Pasos 904 a 907) para iniciar la comunicación según el primer tipo de arquitectura de comunicación, el UE 1 puede transmitir una indicación que indique el descarte del contexto de conexión de RRC a la red (es decir, la RAN 2, o la CN 3, o ambas). Por ejemplo, el UE 1 puede incluir la indicación en un mensaje de RRC (por ejemplo, Solicitud de Conexión de RRC, Configuración de Conexión de RRC Completa), un mensaje de NAS o ambos.
En respuesta a recibir esta indicación del UE 1, la RAN 2 puede reconocer que la información (por ejemplo, contexto de conexión de RRC, asociación de S1AP, contexto de portador de S1-U) retenida en la RAN 2 para la operación de suspensión se permite que se descarte o libere. Del mismo modo, en respuesta a recibir la indicación del UE 1, la CN 3 puede reconocer que la información (por ejemplo, asociación de S1AP, contexto de portador de S1-U) retenida en la CN 3 para la operación de suspensión se permite que sea descartada o liberada. Tal configuración y operación pueden evitar que los estados suspendidos del UE 1 y la red sean inconsistentes unos con otros.
Alternativamente, cuando el UE 1 inicia la transmisión de datos según el primer tipo de arquitectura de comunicación (Paso 903), el UE 1 puede mantener el contexto de conexión de RRC anterior retenido para la operación de suspensión para el segundo tipo de arquitectura de comunicación.
La Figura 10 es un diagrama de secuencias que muestra otro ejemplo del procedimiento de comunicación según esta realización. La Figura 10 muestra un ejemplo de transmisión de datos pequeños Terminados en Móvil (MT). El
Paso 1001 es similar al Paso 901 de la Figura 9. En el Paso 1002, la CN 3 (por ejemplo, la MME, el C-SGN) recibe un mensaje de búsqueda que indica la llegada de datos de SMS Terminados en Móvil dirigidos al UE1. La CN 3 puede recibir datos de SMS en el Paso 1002. En este caso, se puede omitir el Paso 1008 descrito a continuación.
En el paso 1003, la CN 3 envía un mensaje de búsqueda a la RAN 2. Específicamente, la CN 3 envía un mensaje de búsqueda a los eNB respectivos (o las CIoT-BS) asociados con una o más celdas que pertenecen a una o más áreas de seguimiento del UE 1. En el Paso 1004, el UE 1 se busca por la RAN 2.
En el Paso 1005, en respuesta a recibir la búsqueda relacionada con el primer tipo de arquitectura de comunicación mientras que el UE 1 está ejecutando la operación de suspensión para el segundo tipo de arquitectura de comunicación, el UE 1 conmuta del segundo tipo de arquitectura de comunicación al primer tipo de arquitectura de comunicación e inicia la comunicación según el primer tipo de arquitectura de comunicación (es decir, transmisión de datos sobre NAS). Aquí, la búsqueda relacionada con el primer tipo de arquitectura de comunicación puede incluir, por ejemplo, información que indica explícita o implícitamente que se ha de llevar a cabo la transmisión de datos según el primer tipo de arquitectura de comunicación. La información explícita puede ser información que indique uno del primer tipo de arquitectura de comunicación y el segundo tipo de arquitectura de comunicación, o información que indique el primer tipo de arquitectura de comunicación. La información implícita puede ser un ID de portador. Alternativamente, el UE 1 se puede configurar para responder siempre usando el primer tipo de arquitectura de comunicación siempre que se busque.
El procedimiento para la transmisión de datos según el primer tipo de arquitectura de comunicación puede ser similar al procedimiento de transmisión de datos pequeños Terminados en Móvil (MT) para la solución 2 (es decir, DoNAS) descrita en la Bibliografía no de patente 1. Es decir, en el Paso 1006, el UE 1 establece una conexión de RRC y transmite un mensaje de NAS (es decir, Solicitud de Servicio) a la CN 3 usando un mensaje de Configuración de Conexión de RRC Completa (Paso 1007). La CN 3 recibe datos de SMS (Paso 1008), encapsula estos datos de SMS en un mensaje de NAS y envía este mensaje de NAS a la RAN 2 (Paso 1009). La RAN 2 recibe el mensaje de NAS que transporta los datos de SMS desde la CN 3 y transmite un mensaje de RRC (por ejemplo, Transferencia de Información de DL) que contiene este mensaje de NAS al UE 1 (Paso 1010). Como ya se ha descrito, en el momento actual, se supone que ni la solución 2 ni la solución 18 usarán el SRB 2. De este modo, el mensaje de RRC del Paso 1010 se puede transmitir usando el SRB 1 en un Canal de Control Dedicado (DCCH).
De manera similar al ejemplo de la Figura 9, en el ejemplo de la Figura 10, cuando el contexto de conexión de RRC anterior retenido en el UE 1 para la operación de suspensión para el segundo tipo de arquitectura de comunicación se elimina o libera, el UE 1 puede informar a la RAN 2, o la CN 3, o ambas acerca de esta eliminación o liberación. En respuesta a recibir esta indicación del UE 1, la RAN 2 puede reconocer que la información (por ejemplo, contexto de conexión de RRC, asociación de S1AP, contexto de portador de S1-U) retenida en la RAN 2 para la operación de suspensión 1 se permite que se descarte o libere. Del mismo modo, en respuesta a recibir esta indicación del UE 1, la CN 3 puede reconocer que la información (por ejemplo, asociación de S1AP, contexto de portador de S1-U) retenida en la CN 3 para la operación de suspensión se permite que se descarte o libere. Tal configuración y operación pueden evitar que los estados suspendidos del UE 1 y la red sean inconsistentes unos con otros.
Octava realización
En esta realización, un ejemplo de configuración de una red de radiocomunicación es similar al de la Figura 2. El UE 1 según esta realización puede ser un dispositivo de CIoT (por ejemplo, la NB-IoT, la eMTC de LTE), o puede ser otro UE en LTE, LTE Avanzada o versiones modificadas de las mismas.
Como ya se ha descrito, en el momento actual, se supone que la solución 2 (es decir, DoNAS, optimización de EPS de CIoT del Plano de Control) no usa la seguridad de AS y el PDCP. En algunas implementaciones, la comunicación de DoNAS que no usa el PDCP se puede realizar simplemente sin atravesar la capa de PDCP. Alternativamente, un nuevo modo de operación (por ejemplo, Modo Transparente de PDCP (PDCP-TM)) de la capa de PDCP se puede definir para la comunicación de DoNAS que no usa el PDCP. En tal nuevo modo de operación (PDCP-TM), la capa de PDCP no proporciona algunas funciones de la capa de PDCP, incluyendo la función de seguridad de AS (por ejemplo, protección de integridad para SRB, cifrando).
Algunas de las realizaciones descritas anteriormente han mostrado ejemplos en los que el UE 1 ejecuta el procedimiento de Reanudación de Conexión de RRC para iniciar la transmisión de datos según el primer tipo de arquitectura de comunicación mientras que el UE 1 está ejecutando la operación de suspensión para el segundo tipo de arquitectura de comunicación (por ejemplo, las Figs. 4 y 5). Dado que el segundo tipo de arquitectura de comunicación (es decir, almacenamiento en caché de contexto de AS, optimización de EPS de CIoT del Plano de Usuario) usa la seguridad de AS, el UE 1 y la RAN 2 realizan la activación (o confirmación) de seguridad en una de las etapas del procedimiento de Reanudación de Conexión de RRC. De este modo, cuando la seguridad de AS ya se ha activado en el procedimiento de Reanudación de Conexión de RRC, el UE 1 y la RAN 2 pueden aplicar la seguridad de AS (por ejemplo, protección de integridad para la SRB, cifrando) a la comunicación del primer tipo de arquitectura de comunicación (es decir, DoNAS, Optimización de EPS de CIoT del Plano de Control).
Novena Realización
El 3GPP planea comenzar a trabajar en la estandarización de la 5G, es decir, Publicación 14 del 3GPP, en 2016 hacia la introducción de la 5G en 2020. 5G se espera que se realice mediante la mejora/evolución continua de LTE y LTE Avanzada y un desarrollo innovador mediante una introducción de una interfaz aérea de nueva 5G (es decir, una nueva Tecnología de Acceso por Radio (RAT)). La nueva RAT (es decir, RAT de Nueva 5G) soporta, por ejemplo, bandas de frecuencia más altas que las bandas de frecuencia (por ejemplo, 6 GHz o más bajas) soportadas por la LTE/LTE Avanzada y su mejora/evolución. Por ejemplo, la nueva RAT soporta bandas de ondas centimétricas (10 GHz o más altas) y bandas de ondas milimétricas (30 GHz o más altas).
Una frecuencia más alta puede proporcionar una comunicación de tasa más alta. No obstante, debido a sus propiedades de frecuencia, la cobertura de la frecuencia más alta es más local. Por lo tanto, las frecuencias altas se usan para potenciar la capacidad y las tasas de datos en áreas específicas, mientras que una cobertura de área extensa se proporciona por las frecuencias actuales más bajas. Es decir, con el fin de asegurar la estabilidad de la comunicación de RAT de Nueva 5G en bandas de alta frecuencia, se requiere integración estrecha o interfuncionamiento entre frecuencias altas y bajas (es decir, una integración estrecha o interfuncionamiento entre LTE/LTE Avanzada y RAT de Nueva 5G). Un terminal de radio que soporta 5G (es decir, un Equipo de usuario (UE) de 5G) se conecta tanto a una celda de banda de baja frecuencia como a una celda de banda de alta frecuencia (es decir, una celda de LTE/LTE Avanzada y una celda de nueva 5G) usando Agregación de Portadoras (CA) o Conectividad Dual (DC), o una técnica modificada de las mismas.
El término “LTE” usado en esta especificación incluye mejoras de LTE y LTE Avanzada para 5G para proporcionar interfuncionamiento estrecho con la RAT de Nueva 5G, a menos que se indique de otro modo. También se hace referencia a tales mejoras de LTE y LTE Avanzada como LTE Avanzada Pro, LTE o LTE mejorada (eLTE). Además, el término “5G” o “Nueva 5G” en esta especificación se usa, por el bien de la conveniencia, para indicar una interfaz aérea (RAT) que está recién introducida para los sistemas de comunicaciones móviles de quinta generación (5G) y nodos, celdas, capas de protocolo, etc. relacionados con esta interfaz aérea. Los nombres de la interfaz aérea (RAT) recién introducidos y los nodos, celdas y capas de protocolo relacionados con la misma se determinarán en el futuro a medida que avance el trabajo de estandarización. Por ejemplo, se puede hacer referencia a la RAT de LTE como RAT Primaria (P-RAT o pRAT) o RAT Maestra. Mientras tanto, se puede hacer referencia a la RAT de Nueva 5G como RAT Secundaria (S-RAT o sRAT).
La primera a octava realizaciones descritas anteriormente se pueden aplicar a una red de radiocomunicación de 5G que proporciona un interfuncionamiento estrecho entre la RAT de LTE y la RAT de Nueva 5G. En algunas implementaciones, el UE 1, la RAN 2 y la CN 3 pueden realizar uno cualquiera de los procedimientos de conexión descritos en la primera a octava realizaciones en la RAT de LTE luego realizar la transmisión de datos en la RAT de Nueva 5G según un tipo de arquitectura de comunicación determinado (o seleccionado) en el procedimiento de conexión.
Por ejemplo, cuando se usa el primer tipo de arquitectura de comunicación para el UE 1, el UE 1 puede transmitir datos usando un mensaje de T ransferencia de Información de UL en la celda de 5G, en lugar de usar un mensaje de Configuración de Conexión de RRC Completa en la celda de LTE, y recibir datos usando un mensaje de Transferencia de Información de DL en la celda de 5G. Por ejemplo, cuando se usa el segundo tipo de arquitectura de comunicación para el UE 1, el UE 1, la RAN 2 y la CN 3 pueden realizar la suspensión y reanudación de una conexión de RRC en la celda de 5G. En este proceso, el UE 1 y la RAN 2 se pueden conectar tanto a un nodo de red central para la comunicación en la celda de LTE como a un nodo de red central diferente del de la comunicación en la celda de LTE.
Por último, se describirán ejemplos de configuración del UE 1, los nodos en la RAN 2 (por ejemplo, la BS de CIoT, el eNB) y los nodos en la CN 3 (por ejemplo, el C-SGN, la MME) según la pluralidad de realizaciones descritas anteriormente. La Figura 11 es un diagrama de bloques que muestra un ejemplo de configuración del UE 1. Un transceptor de Radiofrecuencia (RF) 1101 realiza un procesamiento de señal de RF analógica para comunicarse con la RAN 2. El procesamiento de señal de RF analógica realizado por el transceptor de RF 1101 incluye conversión ascendente de frecuencia, conversión descendente de frecuencia y amplificación. El transceptor de RF 1101 está acoplado a una antena 1102 y un procesador de banda base 1103. Es decir, el transceptor de RF 1101 recibe datos de símbolos de modulación (o datos de símbolos de OFDM) del procesador de banda base 1103, genera una señal de RF de transmisión y suministra la señal de RF de transmisión a la antena 1102. Además, el transceptor de RF 1101 genera una señal de recepción de banda base en base a una señal de RF de recepción recibida por la antena 1102, y suministra la señal de recepción de banda base al procesador de banda base 1103.
El procesador de banda base 1103 realiza el procesamiento de señal de banda base digital (procesamiento del plano de datos) y el procesamiento del plano de control para radiocomunicación. El procesamiento de señal de banda base digital incluye, por ejemplo, (a) compresión/descompresión de datos, (b) segmentación/concatenación de datos, (c) composición/descomposición de un formato de transmisión (es decir, trama de transmisión), (d) codificación/decodificación de canal, (e) modulación (es decir, correlación de símbolos)/demodulación y (f) generación de datos de símbolos de OFDM (es decir, señal de OFDM de banda base) mediante la Transformada Rápida de Fourier Inversa (IFFT). Mientras tanto, el procesamiento del plano de control incluye gestión de
comunicaciones de la capa 1 (por ejemplo, control de potencia de transmisión), capa 2 (por ejemplo, gestión de recursos de radio y procesamiento de solicitud de repetición automática híbrida (HARQ)) y capa 3 (por ejemplo, señalización con respecto a la conexión, la movilidad y la gestión de llamadas).
En el caso de LTE y LTE Avanzada, por ejemplo, el procesamiento de señal de banda base digital por el procesador de banda base 1103 puede incluir el procesamiento de señal de la capa de Protocolo de Convergencia de Paquetes de Datos (PDCP), la capa de Control de Enlace de Radio (RLC), la capa de Control de Acceso al Medio (MAC) y la capa Física (PHY). Además, el procesamiento del plano de control por el procesador de banda base 1103 puede incluir el procesamiento del protocolo de Estrato Sin Acceso (NAS), el protocolo de RRC y los Elementos de Control de MAC (CE de MAC).
El procesador de banda base 1103 puede incluir un procesador de módem (por ejemplo, Procesador de Señal Digital (DSP)) que realiza el procesamiento de señal de banda base y un procesador de pila de protocolos (por ejemplo, Unidad de Procesamiento Central (CPU) o Unidad de Microprocesamiento (MPU)) que realiza el procesamiento del plano de control. En este caso, el procesador de pila de protocolos, que realiza el procesamiento del plano de control, se puede integrar con un procesador de aplicaciones 1104 descrito en lo siguiente.
También se puede hacer referencia al procesador de aplicaciones 1104 como CPU, MPU, microprocesador o núcleo de procesador. El procesador de aplicaciones 1104 puede incluir una pluralidad de procesadores (núcleos de procesador). El procesador de aplicaciones 1104 carga un programa de software del sistema (Sistema Operativo (OS)) y diversos programas de aplicaciones (por ejemplo, una aplicación de llamada de voz, un navegador WEB, un gestor de correo, una aplicación de operación de cámara, una aplicación de reproducción de música) desde una memoria 1106 o desde otra memoria (no mostrada) y ejecuta estos programas, proporcionando por ello diversas funciones del UE 1.
En algunas implementaciones, que se representan por la línea discontinua (1105) en la Figura 11, el procesador de banda base 1103 y el procesador de aplicaciones 1104 se pueden integrar en un único chip. En otras palabras, el procesador de banda base 1103 y el procesador de aplicaciones 1104 se pueden implementar en un único dispositivo de Sistema en un Chip (SoC) 1105. Se puede hacer referencia a un dispositivo de SoC como Integración a Gran Escala (LSI) del sistema o un conjunto de chips.
La memoria 1106 es una memoria volátil o una memoria no volátil o una combinación de las mismas. La memoria 1106 es una memoria volátil o una memoria no volátil o una combinación de las mismas. La memoria volátil es, por ejemplo, una Memoria de Acceso Aleatorio Estática (SRAM), RAM Dinámica (DRAM) o una combinación de las mismas. La memoria no volátil puede ser una Memoria de Solo Lectura de Máscara (MROM), una ROM Programable Borrable Eléctricamente (EEPROM), una memoria rápida, una unidad de disco duro o cualquier combinación de las mismas. La memoria 1106 puede incluir un dispositivo de memoria interna integrado dentro del procesador de banda base 1103, el procesador de aplicaciones 1104 o el SoC 1105. Además, la memoria 1106 puede incluir una memoria en una Tarjeta Universal de Circuitos Integrados (UICC).
La memoria 1106 puede almacenar uno o más módulos de software (programas informáticos) 1107 incluyendo instrucciones y datos para su procesamiento por el UE 1 descrito en las realizaciones anteriores. En algunas implementaciones, el procesador de banda base 1103 o el procesador de aplicaciones 1104 se pueden cargar con estos uno o más módulos de software 1107 de la memoria 1106 y ejecutar los módulos de software cargados, realizando por ello el procesamiento del UE 1 descrito en las realizaciones anteriores.
La Figura 12 es un diagrama de bloques que muestra un ejemplo de configuración de un nodo (por ejemplo, la BS de CIoT, el eNB) en la RAN 2 según las realizaciones anteriores. Con referencia a la Figura 12, el nodo incluye un transceptor de RF 1201, una interfaz de red 1203, un procesador 1204 y una memoria 1205. El transceptor de RF 1201 realiza un procesamiento de señal de RF analógica para comunicarse con un terminal de radio 1. El transceptor de RF 1201 puede incluir una pluralidad de transceptores.
El transceptor de RF 1201 está acoplado a una antena 1202 y un procesador 1204. El transceptor de RF 1201 recibe datos de símbolos de modulación (o datos de símbolos de OFDM) del procesador 1204, genera una señal de RF de transmisión y suministra la señal de RF de transmisión a la antena 1202. Además, el transceptor de RF 1201 genera una señal de recepción de banda base en base a una señal de RF de recepción recibida por la antena 1202, y suministra la señal de recepción de banda base al procesador 1204.
La interfaz de red 1203 se usa para comunicarse con los nodos de red (por ejemplo, la MME, el C-SGN, la S-GW). La interfaz de red 1203 puede incluir, por ejemplo, una tarjeta de interfaz de red (NIC) conforme a la serie IEEE 802.3.
El procesador 1204 realiza el procesamiento de la señal de banda base digital (procesamiento del plano de datos) y el procesamiento del plano de control para radiocomunicación. En el caso de LTE y LTE Avanzada, por ejemplo, el procesamiento de señal de banda base digital realizado por el procesador 1204 puede incluir el procesamiento de señal de la capa de PDCP, la capa de RLC, la capa de MAC y la capa PHY. Además, el procesamiento del plano de
control realizado por el procesador 1204 puede incluir el procesamiento del protocolo de S1, protocolo de RRC y CE de MAC.
El procesador 1204 puede incluir una pluralidad de procesadores. El procesador de banda base 1204 puede incluir un procesador de módem (por ejemplo, DSP) que realiza el procesamiento de señal de banda base digital y un procesador de pila de protocolos (por ejemplo, CPU o MPU) que realiza el procesamiento del plano de control. La memoria 1205 se compone de una combinación de una memoria volátil y una memoria no volátil. La memoria volátil es, por ejemplo, una SRAM, una DRAM o una combinación de las mismas. La memoria no volátil puede ser una MROM, una PROM, una memoria rápida, una unidad de disco duro o una combinación de las mismas. La memoria 1205 puede incluir un almacenamiento dispuesto de manera separada del procesador 1204. En este caso, el procesador 1204 puede acceder a la memoria 1205 a través de la interfaz de red 1203 o una interfaz de I/O no mostrada.
La memoria 1205 puede almacenar uno o más módulos de software (programas informáticos) 1206 que incluyen instrucciones y datos para el procesamiento por el nodo en la RAN 2 (por ejemplo, la BS de CIoT, el eNB) descrito en las realizaciones anteriores. En algunas implementaciones, el procesador 1204 puede cargar estos uno o más módulos de software desde la memoria 1205 y ejecutar los módulos de software cargados, realizando por ello el procesamiento del nodo en la RAN 2 descrito en las realizaciones anteriores.
La Figura 13 es un diagrama de bloques que muestra un ejemplo de configuración de un nodo (por ejemplo, el C-SGN, la MME) en la CN 3 según las realizaciones anteriores. Con referencia a la Figura 13, el nodo incluye una interfaz de red 1301, un procesador 1302 y una memoria 1303. La interfaz de red 1301 se usa para comunicarse con los nodos de red (por ejemplo, el C-SGN, la MME, el HSS, la S-GW, la P-GW, la BS de CIoT, el eNB). La interfaz de red 1301 puede incluir, por ejemplo, una tarjeta de interfaz de red (NIC) conforme a las series IEEE 802.3.
El procesador 1302 carga uno o más módulos de software (programas informáticos) de la memoria 1303 y ejecuta los módulos de software cargados, realizando por ello el procesamiento del nodo en la CN 3 (por ejemplo, el C-SGN, la MME) descrito en las realizaciones anteriores. El procesador 1302 puede ser, por ejemplo, un microprocesador, una MPU o una CPU. El procesador 1302 puede incluir una pluralidad de procesadores.
La memoria 1303 se compone de una combinación de una memoria volátil y una memoria no volátil. La memoria 1303 puede incluir un almacenamiento dispuesto de manera separada del procesador 1302. En este caso, el procesador 1302 puede acceder a la memoria 1303 a través de una interfaz de I/O (no mostrada).
Como se ha descrito con referencia a las Figs. 11 y 13, cada uno de los procesadores incluidos en el UE 1, el nodo en la RAN 2 y el nodo en la CN 3 según las realizaciones descritas anteriormente ejecuta uno o más programas que incluyen instrucciones para hacer que un ordenador ejecute el algoritmo descrito con referencia a los dibujos. Estos programas se pueden almacenar y proporcionar a un ordenador usando cualquier tipo de medio legible por ordenador no transitorio. Los medios legibles por ordenador no transitorios incluyen cualquier tipo de medio de almacenamiento tangible. Ejemplos de medios legibles por ordenador no transitorios incluyen medios de almacenamiento magnético (tales como disquetes, cintas magnéticas, unidades de disco duro, etc.), medios de almacenamiento magnético óptico (por ejemplo, discos magnetoópticos), Memoria de Solo Lectura de Disco Compacto (CD-ROM), CD-R, CD-R/W, memorias de semiconductores (tales como ROM de Máscara, ROM Programable (PROM), PRo M Borrable (EPROM), ROM rápida, Memoria de Acceso Aleatorio (RAM)). Estos programas se pueden proporcionar a un ordenador usando cualquier tipo de medios legibles por ordenador transitorios. Ejemplos de medios legibles por ordenador transitorios incluyen señales eléctricas, señales ópticas y ondas electromagnéticas. Se pueden usar medios legibles por ordenador transitorios para proporcionar programas a un ordenador a través de una línea de comunicación por cable (por ejemplo, cables eléctricos y fibras ópticas) o una línea de comunicación inalámbrica.
Otras realizaciones
Cada una de las realizaciones anteriores se puede usar individualmente, o dos o más de las realizaciones se pueden combinar apropiadamente unas con otras.
En las realizaciones anteriores, cuando el UE 1 cambia la celda de servicio desde la celda en la que se ha suspendido la conexión de RRC a otra celda (por ejemplo, reselección de celda, conectar después de desconectar), puede ser preferible que el UE 1 pueda saber si las funciones descritas en la realización anterior están disponibles en la celda de servicio después del cambio de celda. De este modo, la RAN 2 puede difundir un elemento de información que indique si las funciones se soportan en la celda de servicio. Por ejemplo, la RAN 2 (por ejemplo, el eNB, la CIoT-BS) puede difundir este elemento de información en las celdas respectivas en la RAN 2. El elemento de información puede indicar si la celda en la que se difunde este elemento de información soporta las funciones. Además, el elemento de información puede indicar si una celda adyacente soporta las funciones.
La RAN 2 descrita en las realizaciones anteriores puede ser una Red de Acceso por Radio en la Nube (C-RAN). También se hace referencia a la C-RAN como RAN centralizada. Específicamente, los procesos y las operaciones
realizados por la RAN 2, o la BS de CIoT o el eNB en la RAN 2, descritos en las realizaciones anteriores se pueden proporcionar por una o una combinación de una Unidad Digital (DU) y una Unidad de Radio (RU) incluida en la arquitectura de C-RAN. También se hace referencia a la DU como Unidad de Banda Base (BBU). También se hace referencia a la RU como Cabecera de Radio Remota (RRH) o Equipo de Radio Remoto (RRE). Es decir, los procesos y las operaciones realizados por la RAN 2, la BS de CIoT o el eNB descritos en las realizaciones anteriores se pueden proporcionar por una cualquiera o más estaciones de radio (es decir, nodos de RAN).
Las realizaciones descritas anteriormente son meramente ejemplos de aplicaciones de las ideas técnicas obtenidas por los inventores. Estas ideas técnicas no se limitan a las realizaciones descritas anteriormente, y pueden hacerse diversos cambios y modificaciones a las mismas.
Por ejemplo, la totalidad o parte de las realizaciones descritas anteriormente se puede describir como, pero no limitadas a, las siguientes notas complementarias.
La presente solicitud se basa y reivindica el beneficio de prioridad de la Solicitud de Patente Japonesa N° 2016 020291, presentada el 4 de febrero de 2016.
Lista de signos de referencia
1 Equipo de Usuario (UE)
2 Red de Acceso por Radio (RAN)
3 Red Central (c N)
4 SERVIDOR DE APLICACIONES
6 Pasarela de Servicio (S-GW)/Pasarela de Red de Paquetes de Datos (P-GW)
1103 PROCESADOR DE BANDA BASE
1104 PROCESADOR DE APLICACIONES
1106 MEMORIA
1204 PROCESADOR
1205 MEMORIA
1302 PROCESADOR
1303 MEMORIA
Claims (8)
1. Un terminal de radio (1) que comprende:
una memoria (1106); y
al menos un procesador (1103) acoplado a la memoria (1106), en el que al menos un procesador (1103) está configurado para soportar una pluralidad de tipos de arquitecturas de comunicación,
la pluralidad de tipos de arquitecturas de comunicación incluye: a) un primer tipo de arquitectura de comunicación en el que un paquete de datos se transmite a través de un plano de control y b) un segundo tipo de arquitectura de comunicación en el que un paquete de datos se transmite a través de un plano de usuario y que implica la suspensión y reanudación de una conexión de Control de Recursos de Radio, RRC, la suspensión de la conexión de RRC incluye retener en el terminal de radio un contexto de una conexión de RRC anterior mientras que el terminal de radio está en un estado inactivo de RRC,
la reanudación de conexión de RRC incluye la reutilización del contexto retenido en el momento de una configuración de una conexión de RRC posterior con el fin de que el terminal de radio haga una transición del estado inactivo de RRC a un estado conectado de RRC, y
en el que al menos un procesador (1103) está configurado además para, en respuesta a la aparición (S402, S502, S602) de una solicitud de transmisión de datos específicos según el primer tipo de arquitectura de comunicación cuando el terminal de radio ya ha sido configurado (S401, S501, S601) por una red para usar tanto el primer como el segundo tipos de arquitecturas de comunicación y el terminal de radio está adaptado para ejecutar la suspensión (S401, S501, S601) para el segundo tipo de arquitectura de comunicación, transmitir (S403, S503, S603) datos usando el primer tipo de arquitectura de comunicación mientras que se conserva el contexto.
2. El terminal de radio según la reivindicación 1, en el que
al menos un procesador (1103) está configurado para, cuando el terminal de radio se ha configurado (S401, S501, S601) por la red para usar tanto el primer como el segundo tipos de arquitecturas de comunicación, determinar cuál del primer y segundo tipos de arquitecturas de comunicación se ha de usar, dependiendo de si la comunicación solicitada es la transmisión de datos específica.
3. El terminal de radio según la reivindicación 1, en el que
al menos un procesador (1103) está configurado para, tras iniciar la comunicación según el primer tipo de arquitectura de comunicación cuando el terminal de radio está ejecutando la suspensión para el segundo tipo de arquitectura de comunicación, transmitir un mensaje de Estrato Sin Acceso, NAS, que contiene datos del primer tipo de arquitectura de comunicación usando un mensaje de RRC que se usa para la reanudación de la conexión de RRC, y
el mensaje de RRC incluye una indicación que indica la transmisión de datos sobre un Estrato Sin Acceso, NAS.
4. El terminal de radio según la reivindicación 1 o 3, en el que
al menos un procesador (1103) está configurado para, tras iniciar la comunicación según el primer tipo de arquitectura de comunicación cuando el terminal de radio está ejecutando la suspensión para el segundo tipo de arquitectura de comunicación, transmitir el mensaje de Estrato Sin Acceso, NAS que contiene los datos del primer tipo de arquitectura de comunicación usando un mensaje de RRC que se usa para la reanudación de la conexión de RRC, y
el mensaje de NAS incluye una indicación que indica la transmisión de datos sobre un Estrato Sin Acceso, NAS.
5. El terminal de radio según la reivindicación 1, en el que
al menos un procesador (1103) está configurado para, tras iniciar la comunicación según el primer tipo de arquitectura de comunicación mientras que el terminal de radio está ejecutando la suspensión para el segundo tipo de arquitectura de comunicación, transmitir un mensaje de reanudación de conexión de RRC usado para la reanudación de conexión de RRC, y
el mensaje de reanudación de conexión de RRC indica una causa de establecimiento asociada con la transmisión de datos sobre un Estrato Sin Acceso, NAS.
6. El terminal de radio según la reivindicación 5, en el que
la transmisión de datos específica es una transmisión de datos no de Protocolo de Internet, no de IP, o transmisión de Servicio de Mensajes Cortos, SMS,
al menos un procesador (1103) está configurado para operar como una capa de NAS que proporciona gestión de movilidad y gestión de sesiones y como una capa de Estrato de Acceso, AS, que proporciona control de recursos de radio, y
la capa de NAS está configurada para, en respuesta a la aparición de la solicitud de la transmisión de datos específicos mientras que el terminal de radio está ejecutando la suspensión para el segundo tipo de arquitectura de comunicación, generar un mensaje de NAS que transporta datos y proporciona una solicitud de establecimiento de conexión de RRC a la capa de AS, la solicitud de establecimiento de conexión de RRC que contiene la causa de establecimiento asociada con la transmisión de datos a través del NAS y un tipo de llamada asociado con la transmisión específica.
7. Un método de un terminal de radio (1), el método que comprende:
estar configurado por una red con al menos uno de una pluralidad de tipos de arquitecturas de comunicación, en el que
la pluralidad de tipos de arquitecturas de comunicación incluye: a) un primer tipo de arquitectura de comunicación en el que se transmite un paquete de datos a través de un plano de control; y b) un segundo tipo de arquitectura de comunicación en el que un paquete de datos se transmite a través de un plano de usuario y que implica la suspensión y reanudación de una conexión de Control de Recursos de Radio, RRC, la suspensión de la conexión de RRC incluye retener en el terminal de radio un contexto de una conexión de RRC anterior mientras que el terminal de radio está en un estado inactivo de RRC,
la reanudación de conexión de RRC incluye la reutilización del contexto retenido en el momento de la configuración de una conexión de RRC posterior con el fin de que el terminal de radio haga una transición del estado inactivo de RRC a un estado conectado de RRC, y
el método que comprende además, en respuesta a la aparición (S402, S502, S602) de una solicitud de transmisión de datos específicos según el primer tipo de arquitectura de comunicación cuando el terminal de radio ya se ha configurado (S401, S501, S601) por la red para usar el primer y segundo tipos de arquitecturas de comunicación y el terminal de radio está ejecutando la suspensión (S401, S501, S601) para el segundo tipo de arquitectura de comunicación, transmitiendo (S403, S503, S603) datos usando el primer tipo de arquitectura de comunicación mientras que se retiene el contexto.
8. Un programa que incluye instrucciones que, cuando se carga en un ordenador, hace que el ordenador realice el método según la reivindicación 7.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2016020291 | 2016-02-04 | ||
PCT/JP2016/087351 WO2017134939A1 (ja) | 2016-02-04 | 2016-12-15 | 無線端末、無線局、及びこれらの方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2901117T3 true ES2901117T3 (es) | 2022-03-21 |
Family
ID=59499493
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES16889422T Active ES2901117T3 (es) | 2016-02-04 | 2016-12-15 | Terminal de radio, método y programa para el mismo |
Country Status (7)
Country | Link |
---|---|
US (3) | US10506389B2 (es) |
EP (2) | EP3413681B1 (es) |
JP (4) | JP6587001B2 (es) |
KR (4) | KR102140912B1 (es) |
CN (2) | CN114374939B (es) |
ES (1) | ES2901117T3 (es) |
WO (1) | WO2017134939A1 (es) |
Families Citing this family (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10506389B2 (en) * | 2016-02-04 | 2019-12-10 | Nec Corporation | Radio terminal, radio station, and method therefor |
WO2017155259A1 (ko) * | 2016-03-09 | 2017-09-14 | 엘지전자 주식회사 | 사용자 데이터의 전송을 위한 베어러를 설정하는 방법 및 장치 |
CN107426801A (zh) * | 2016-05-23 | 2017-12-01 | 中兴通讯股份有限公司 | 一种智能卡的控制方法、装置、终端设备及智能卡 |
US10659976B2 (en) * | 2016-06-29 | 2020-05-19 | Nokia Technologies Oy | Paging enhancement for signaling optimization |
WO2018030259A1 (ja) * | 2016-08-10 | 2018-02-15 | 京セラ株式会社 | 無線端末及び基地局 |
US10893456B2 (en) * | 2016-10-26 | 2021-01-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Wireless device, radio network nodes and methods performed therein for handling neighbour relationships in a wireless network |
JP2020501410A (ja) * | 2016-11-04 | 2020-01-16 | 華為技術有限公司Huawei Technologies Co.,Ltd. | データパケット処理方法、制御プレーンネットワーク要素、及びユーザプレーンネットワーク要素 |
EP3639616A1 (en) * | 2017-06-16 | 2020-04-22 | Telefonaktiebolaget LM Ericsson (PUBL) | Resuming a connection in a wireless communication system |
CN109548109B (zh) * | 2017-08-14 | 2021-03-09 | 电信科学技术研究院 | 一种ue和网络状态不匹配的处理方法及装置、存储介质 |
US10581495B2 (en) * | 2017-08-18 | 2020-03-03 | Nokia Technologies Oy | Physical layer configuration continuity during radio resource control restoration |
US10681593B2 (en) * | 2017-11-30 | 2020-06-09 | At&T Intellectual Property I, L.P. | Session transfer for packet data network connection |
CA3088463C (en) | 2018-02-20 | 2023-01-03 | Guangdong Oppo Mobile Telecommunications Corp., Ltd. | Method, system and computer programs for the transmission of infrequent small data in a telecommunication system |
CN110312296B (zh) * | 2018-03-27 | 2023-09-08 | 夏普株式会社 | 用户设备执行的方法、基站执行的方法、用户设备和基站 |
EP3570627B1 (en) * | 2018-05-09 | 2024-01-17 | HTC Corporation | Device of handling a resume cause in a radio resource control message |
CN109246799A (zh) * | 2018-09-05 | 2019-01-18 | 江苏鑫软图无线技术股份有限公司 | NB-IoT系统下实现CIoT EPS优化转换的方法 |
US10856333B2 (en) * | 2018-09-25 | 2020-12-01 | Hughes Network Systems, Llc | Efficient transport of internet of things (IoT) traffic in terrestrial wireless and satellite networks |
EP3925182A1 (en) * | 2019-02-13 | 2021-12-22 | Telefonaktiebolaget LM Ericsson (publ) | Methods and apparatuses for alternative data over non-access stratum, donas, data delivery in a roaming scenario |
EP3915334A1 (en) * | 2019-02-14 | 2021-12-01 | Google LLC | Resuming radio connections in a communication network |
WO2020175490A1 (en) * | 2019-02-27 | 2020-09-03 | Sharp Kabushiki Kaisha | Radio access network and methods |
WO2020175658A1 (en) * | 2019-02-28 | 2020-09-03 | Sharp Kabushiki Kaisha | Radio access network and methods |
WO2021007735A1 (en) * | 2019-07-15 | 2021-01-21 | Qualcomm Incorporated | Rrc layer based suspend and resume for multi-sim ue |
CN113498152A (zh) * | 2020-04-01 | 2021-10-12 | 夏普株式会社 | 由用户设备执行的方法以及用户设备 |
CN113825186B (zh) * | 2020-06-19 | 2023-08-01 | 维沃移动通信有限公司 | 离开网络的控制方法、装置和通信设备 |
Family Cites Families (35)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100253283B1 (ko) * | 1997-04-07 | 2000-04-15 | 김영환 | 메모리소자의소모전류감소회로 |
US7011153B2 (en) * | 2003-12-23 | 2006-03-14 | Schlumberger Technology Corporation | Hydraulically released inflation tool for permanent bridge plug |
CN101163026B (zh) * | 2006-10-13 | 2011-04-20 | 中兴通讯股份有限公司 | 一种无线网络控制器获取无线接入承载标识的实现方法 |
CN101257374B (zh) * | 2007-03-01 | 2010-05-19 | 鼎桥通信技术有限公司 | 实现广播/组播业务与专用业务并发的方法及其系统 |
US8331322B2 (en) * | 2009-01-22 | 2012-12-11 | Htc Corporation | Method of handling radio bearer resumption, wireless communication device and wireless communication system thereof |
CN102045713A (zh) * | 2009-10-15 | 2011-05-04 | 中兴通讯股份有限公司 | 业务连接重建的方法和实现系统 |
CN102291821A (zh) * | 2010-06-18 | 2011-12-21 | 电信科学技术研究院 | 一种恢复rrc连接的方法及中继设备rn |
CN102340886B (zh) * | 2010-07-22 | 2014-04-16 | 大唐移动通信设备有限公司 | 一种重建立rrc连接的方法、装置及系统 |
GB2493349A (en) * | 2011-07-29 | 2013-02-06 | Intellectual Ventures Holding 81 Llc | Mobile communications network with simplified handover |
US9258839B2 (en) * | 2011-08-12 | 2016-02-09 | Blackberry Limited | Other network component receiving RRC configuration information from eNB |
EP2557890B1 (en) * | 2011-08-12 | 2019-07-17 | BlackBerry Limited | Simplified ue + enb messaging |
US9504081B2 (en) * | 2011-08-12 | 2016-11-22 | Blackberry Limited | Suspending a connection in a wireless communication system |
US9155121B2 (en) * | 2012-03-27 | 2015-10-06 | Blackberry Limited | Re-establishment of suspended RRC connection at a different eNB |
EP2645804B1 (en) * | 2012-03-27 | 2017-12-20 | BlackBerry Limited | Re-establishment of suspended RRC connection at a different ENB |
US8923880B2 (en) * | 2012-09-28 | 2014-12-30 | Intel Corporation | Selective joinder of user equipment with wireless cell |
US8768305B1 (en) * | 2012-10-09 | 2014-07-01 | Sprint Communications Company L.P. | Reestablishing a mobile device radio resource control connection |
WO2015005853A2 (en) * | 2013-07-09 | 2015-01-15 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus in a telecommunication system |
US9265085B2 (en) * | 2013-12-31 | 2016-02-16 | Alcatel Lucent | Methods and systems for optimizing short data burst services over an LTE network |
CN105659691A (zh) * | 2014-03-19 | 2016-06-08 | Lg电子株式会社 | 用于服务请求过程的执行方法和用户设备 |
CN104980980A (zh) * | 2014-04-10 | 2015-10-14 | 电信科学技术研究院 | 一种建立连接的方法、系统和设备 |
JP5691118B1 (ja) | 2014-07-15 | 2015-04-01 | 株式会社エム・イ−・ティ− | 活性炭製造装置及び活性炭製造方法 |
PL3213557T3 (pl) * | 2014-10-28 | 2020-06-15 | Telefonaktiebolaget Lm Ericsson (Publ) | Węzły sieciowe, urządzenie użytkownika i ich sposoby do obsługi połączenia między urządzeniem użytkownika a bezprzewodową siecią komunikacyjną |
US10667321B2 (en) * | 2015-02-09 | 2020-05-26 | Intel IP Corporation | Evolved Node-B, user equipment, and methods for transition between idle and connected modes |
JP6208296B1 (ja) * | 2015-11-05 | 2017-10-04 | 株式会社Nttドコモ | ユーザ装置、基地局、及び接続確立方法 |
KR102051552B1 (ko) * | 2015-12-29 | 2019-12-03 | 엘지전자 주식회사 | 사용자 데이터의 전송을 위한 베어러를 설정하는 방법 및 장치 |
US10826867B2 (en) * | 2016-01-08 | 2020-11-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Simplified wireless connectivity for a cellular communications system |
CN107251643B (zh) * | 2016-01-08 | 2019-07-05 | 瑞典爱立信有限公司 | 用于无线电资源控制的方法和设备以及计算机可读介质 |
EP3400751A4 (en) * | 2016-01-08 | 2019-10-02 | Nokia Technologies Oy | OPTIMIZATION OF USER PLAN FOR THE INTERNET OF NARROW-BANDED OBJECTS |
CN106961456B (zh) * | 2016-01-11 | 2022-01-18 | 北京三星通信技术研究有限公司 | 决定iot业务方法和设备、iot业务行为控制方法和设备 |
WO2017123417A1 (en) * | 2016-01-12 | 2017-07-20 | Intel Corporation | CELLULAR INTERNET OF THINGS (CIoT) OPTIMIZATIONS FOR NARROWBAND (NB) AND NON-NB IoT NETWORKS |
US10880710B2 (en) * | 2016-01-18 | 2020-12-29 | Samsung Electronics Co., Ltd. | Method and apparatus for communication of terminal in mobile communication system |
JP2019050437A (ja) * | 2016-01-19 | 2019-03-28 | シャープ株式会社 | 端末装置、c−sgnおよび通信制御方法 |
JP2019050435A (ja) * | 2016-01-19 | 2019-03-28 | シャープ株式会社 | 端末装置、c−sgnおよび通信制御方法 |
US10779260B2 (en) * | 2016-02-02 | 2020-09-15 | Lg Electronics Inc. | Method and apparatus for paging with resume ID for suspended user equipment in wireless communication system |
US10506389B2 (en) * | 2016-02-04 | 2019-12-10 | Nec Corporation | Radio terminal, radio station, and method therefor |
-
2016
- 2016-12-15 US US16/069,777 patent/US10506389B2/en active Active
- 2016-12-15 KR KR1020207006932A patent/KR102140912B1/ko active IP Right Grant
- 2016-12-15 KR KR1020207021771A patent/KR102172126B1/ko active IP Right Grant
- 2016-12-15 EP EP16889422.8A patent/EP3413681B1/en active Active
- 2016-12-15 EP EP21205405.0A patent/EP3965526A1/en active Pending
- 2016-12-15 KR KR1020187022298A patent/KR102092495B1/ko active IP Right Grant
- 2016-12-15 WO PCT/JP2016/087351 patent/WO2017134939A1/ja active Application Filing
- 2016-12-15 CN CN202210044446.9A patent/CN114374939B/zh active Active
- 2016-12-15 ES ES16889422T patent/ES2901117T3/es active Active
- 2016-12-15 KR KR1020207030464A patent/KR102226650B1/ko active IP Right Grant
- 2016-12-15 JP JP2017565424A patent/JP6587001B2/ja active Active
- 2016-12-15 CN CN201680081095.1A patent/CN108605376B/zh active Active
-
2019
- 2019-09-11 JP JP2019165025A patent/JP6787459B2/ja active Active
- 2019-10-18 US US16/657,407 patent/US10880700B2/en active Active
-
2020
- 2020-10-20 JP JP2020175871A patent/JP7006752B2/ja active Active
- 2020-11-25 US US17/104,128 patent/US11388560B2/en active Active
-
2021
- 2021-12-27 JP JP2021211784A patent/JP7306444B2/ja active Active
Also Published As
Publication number | Publication date |
---|---|
EP3413681A4 (en) | 2020-01-29 |
JP2022037204A (ja) | 2022-03-08 |
US20190028860A1 (en) | 2019-01-24 |
JP7306444B2 (ja) | 2023-07-11 |
KR102092495B1 (ko) | 2020-03-23 |
JP6587001B2 (ja) | 2019-10-09 |
KR102226650B1 (ko) | 2021-03-10 |
CN108605376B (zh) | 2022-01-25 |
KR20200029617A (ko) | 2020-03-18 |
KR20200092434A (ko) | 2020-08-03 |
CN108605376A (zh) | 2018-09-28 |
US11388560B2 (en) | 2022-07-12 |
KR20180100381A (ko) | 2018-09-10 |
KR102140912B1 (ko) | 2020-08-03 |
JP2020010379A (ja) | 2020-01-16 |
JP7006752B2 (ja) | 2022-01-24 |
JP6787459B2 (ja) | 2020-11-18 |
KR20200123290A (ko) | 2020-10-28 |
CN114374939A (zh) | 2022-04-19 |
US20210160665A1 (en) | 2021-05-27 |
JP2021036679A (ja) | 2021-03-04 |
WO2017134939A1 (ja) | 2017-08-10 |
KR102172126B1 (ko) | 2020-10-30 |
CN114374939B (zh) | 2023-08-25 |
US20200053520A1 (en) | 2020-02-13 |
EP3965526A1 (en) | 2022-03-09 |
US10506389B2 (en) | 2019-12-10 |
US10880700B2 (en) | 2020-12-29 |
EP3413681A1 (en) | 2018-12-12 |
EP3413681B1 (en) | 2021-12-08 |
JPWO2017134939A1 (ja) | 2018-10-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2901117T3 (es) | Terminal de radio, método y programa para el mismo | |
JP6969636B2 (ja) | 無線端末、無線端末における方法、及び無線局 | |
ES2777629T3 (es) | Método, estación base y sistema de planificación de datos | |
BR122020023536B1 (pt) | Terminal de rádio, estação de rádio, nó de rede núcleo e método nos mesmos |