ES2936657T3 - Métodos, aparatos y programas informáticos para restablecer una conexión de Control de Recuso de Radio (RRC) - Google Patents

Métodos, aparatos y programas informáticos para restablecer una conexión de Control de Recuso de Radio (RRC) Download PDF

Info

Publication number
ES2936657T3
ES2936657T3 ES20201160T ES20201160T ES2936657T3 ES 2936657 T3 ES2936657 T3 ES 2936657T3 ES 20201160 T ES20201160 T ES 20201160T ES 20201160 T ES20201160 T ES 20201160T ES 2936657 T3 ES2936657 T3 ES 2936657T3
Authority
ES
Spain
Prior art keywords
authentication token
target enb
input
target
ciot
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
Application number
ES20201160T
Other languages
English (en)
Inventor
Vesa Lehtovirta
Monica Wifvesson
Prajwol Kumar Nakarmi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2936657T3 publication Critical patent/ES2936657T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
    • H04W36/0038—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information of security context information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/18—Management of setup rejection or failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/19—Connection re-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/25—Maintenance 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
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/20—Interfaces between hierarchically similar devices between access points
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un método para restablecer una conexión de Control de Recursos de Radio, RRC, entre un Equipo de Usuario (1), UE, y un NodoB evolucionado de destino (3), eNB de destino, siendo realizado el método por el UE (1) y que comprende: recibir (S100) un mensaje de restablecimiento de conexión RRC del eNB de destino (3), el mensaje de restablecimiento de conexión RRC que incluye un enlace descendente, DL, token de autenticación que ha sido generado por una entidad de gestión de movilidad (4) y ha tenido una clave de integridad de estrato sin acceso y la identidad de una celda objetivo como entrada; y autenticar (S110) el token de autenticación de DL recibido. También se describen un UE, un eNB de destino, un eNB de origen y una entidad de gestión de la movilidad, así como métodos y programas informáticos relacionados con los mismos. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Métodos, aparatos y programas informáticos para restablecer una conexión de Control de Recuso de Radio (RRC) Campo técnico
La invención se refiere a métodos, Equipo de Usuario, NodeB objetivo, Entidad de Gestión de Movilidad y programas informáticos para restablecer una conexión de Control de Recursos de Radio para la optimización de Internet Celular de las Cosas de Plano de Control.
Antecedentes
Las optimizaciones de Internet Celular de las Cosas (CIoT) de Plano de Control (CP) (también conocida como Datos Sobre Estrato de No Acceso (NAS) (DoNAS)) es una solución para transportar datos sobre NAS según se especifica en la especificación técnica TS 23.40l V14.2.0 del Proyecto Partnership de 3a Generación (3GPP), cláusula 5.3.4B (y otras especificaciones, p. ej., TS 24.301 V14.2.0). Las características de seguridad están especificadas en TS 33.401 V14.1.0, cláusula 8.2. El impacto de seguridad de la solución básica es muy limitado. El propósito de la característica de DoNAS es enviar datos sobre señalización de NAS sin establecer portadoras de radio de datos (DRBs) y sin establecer seguridad de Estrato de Acceso (AS). La intención es ahorrar señalización. La Fig. 1, que corresponde a la Figura 5.3.4B.2-1 de TS 23.401 V14.2.0, ilustra el principio de los DoNAS.
El artículo de trabajo contenido en el documento R3-161324 de 3GPP busca incrementos de movilidad para CIoT de CP. Los traspasos no están soportados para CIoT de CP, pero un Equipo de Usuario (UE) puede moverse en cualquier caso, causando un fallo del enlace de radio (RLF) cuando el UE está en modo conectado (es decir, tiene conexión de Control de Recurso de Radio (RRC) con un NodeB evolucionado (eNB)). Esto ha presentado el problema de qué hacer en ese caso. Puesto que la seguridad de AS no está soportada para la característica de CIoT de CP, los mecanismos existentes para RLF no pueden ser usados de forma segura como tales. En otras palabras, no es aceptable desde el punto de vista de la seguridad usar el mecanismo de gestión de RLF existente en el CIoT de CP.
La Capa de RRC está en los sistemas de LTE (Evolución de Largo Plazo) actuales, véase p. ej., 3GPP TS 36.331 V14.1.0, especificada como que incluye un elemento de información (IE) denominado ShortMAC-I que se usa para identificación del UE, por ejemplo, durante procedimientos de Restablecimiento de Conexión de RRC. El cálculo del ShortMAC-I incluye lo siguiente como entrada:
- Clave de integridad de RRC: CADENA DE BITS (TAMAÑO (128))
- Identidad de la célula objetivo: CADENA DE BITS (TAMAÑO (28))
- Identidad de célula física de la célula fuente: NÚMERO ENTERO (0, ..., 503)
- C-RNTI (Identificador Temporal de Red de Radio de la Célula) del UE en la célula fuente: CADENA DE BITS (TAMAÑO (16))
La función usada está especificada en TS 33.401 V14.1.0.
La Capa de RRC está en los sistemas de LTE especificada como que incluye un elemento de información (IE) denominado ShortResumeMAC-I que se utiliza para identificación del UE, por ejemplo, durante procedimientos de Reanudación de Conexión de RRC. El cálculo del ShortResumeMAC-I incluye lo siguiente como entrada:
- Clave de integridad de RRC: CADENA DE BITS (TAMAÑO (128))
- Identidad de la célula objetivo: CADENA DE BITS (TAMAÑO (28))
- Identidad de célula física de la célula fuente: NÚMERO ENTERO (0, ..., 503)
- C-RNTI del UE en la célula fuente: CADENA DE BITS (TAMAÑO (16))
- Constante de reanudación.
Obsérvese que el cálculo de ShortResumeMAC-I incluye adicionalmente una constante de reanudación, la cual permite la diferenciación de ShortMAC-I respecto a ResumeShortMAC-I. La función = usada está especificada en TS 33.401 V14.1.0.
Ghizlande Orhanou et al.: “EPS Confidentiality and Integrity mechanisms Algorithmic Approach”, IJCSI Diario Internacional de temas de informática, vol. 7, núm. 4, describe señalización de RRC y de NAS. También se describe una clave de integridad KNASint para tráfico de NAS.
Compendio
Un objeto de la invención consiste en habilitar una señalización reducida durante el restablecimiento de una conexión de control de recurso de radio.
Otro objeto de la invención consiste en habilitar autenticación de un eNB objetivo por parte del UE durante restablecimiento de conexión de RRC.
Según un primer aspecto de la invención, se presenta un método para el restablecimiento de una conexión de Control de Recurso de Radio (RRC) entre un Equipo de Usuario (UE) y un NodeB evolucionado objetivo (eNB objetivo) para la optimización de Internet Celular de las Cosas de Plano de Control (CP CIoT). El método se lleva a cabo por medio del UE y comprende:
recibir un mensaje de Restablecimiento de Conexión de RRC desde el eNB objetivo, incluyendo el mensaje de Restablecimiento de Conexión de RRC una señal de muestra de autenticación de enlace descendente (DL) que ha sido generada por una Entidad de Gestión de Movilidad (MME) y que ha tenido una clave de integridad de Estrato de No Acceso (NAS) y una identidad de la célula objetivo como entrada, y
autenticar la señal de muestra de autenticación de DL recibida.
Con ello se consigue, inter alia, que el UE esté habilitado para autenticar un eNB durante el restablecimiento de conexión de RRC, tal como el restablecimiento de conexión de RRC para optimización de IoT de EPS CP, con la ayuda de una clave de integridad de NAS y la identidad de la célula objetivo. De ese modo, no se necesita que se cree ninguna clave de Estrato de Acceso (AS), lo que es muy beneficioso, por ejemplo debido a que las claves de NAS deben ser generadas de todos modos, mientras que las claves de AS tendrían que ser generadas solamente para ser usadas en restablecimiento de conexión de RRC.
El método puede comprender también una etapa de cálculo de una señal de muestra de autenticación de enlace ascendente (UL) con la clave de integridad de NAS como entrada, y el envío de una solicitud de restablecimiento de conexión de RRC que incluya la señal de muestra de autenticación de UL, al eNB objetivo. La señal de muestra de autenticación de UL puede ser calculada, en ese caso, con la identidad de la célula objetivo como entrada.
Un segundo aspecto se refiere a un método para el restablecimiento de una conexión de RRC entre un UE y un eNB objetivo, para la optimización de CP CIoT y se lleva a cabo por medio del eNB objetivo. El método comprende: recibir, desde una MME, un mensaje que incluye una señal de muestra de autenticación de DL que ha sido generada por la MME, en donde la señal de muestra de autenticación de DL ha sido generada con una clave de integridad de NAS y una identidad de la célula objetivo como entrada, y
enviar un mensaje de Restablecimiento de Conexión de RRC al UE, incluyendo el mensaje de Restablecimiento de Conexión de RRC la señal de muestra de autenticación de DL.
En una realización del segundo aspecto, el método comprende recibir desde el UE, una solicitud de restablecimiento de conexión de RRC que incluye una señal de muestra de autenticación de UL, en donde la señal de muestra de autenticación de UL ha sido calculada por el UE con la clave de integridad de NAS como entrada. La señal de muestra de autenticación de UL puede entonces haber sido calculada por el UE con la identidad de la célula objetivo como entrada. Un tercer aspecto se refiere a un método para restablecer una conexión de RRC entre un UE y un eNB objetivo, para la optimización de CP CIoT, y se lleva a cabo por medio de una MME. El método comprende:
generar una señal de muestra de autenticación de DL con una clave de integridad de NAS y una identidad de la célula objetivo como entrada, y
enviar un mensaje que incluya la señal de muestra de autenticación de DL generada, al eNB objetivo.
El método según el tercer aspecto puede comprender:
recibir una señal de muestra de autenticación de UL desde el eNB objetivo, habiendo sido generada dicha señal de muestra de autenticación de UL por parte del UE con la clave de integridad de NAS como entrada, y verificar la señal de muestra de autenticación de UL.
La señal de muestra de autenticación de UL puede haber sido generada por el UE con la identidad de la célula objetivo como entrada.
Un cuarto aspecto de la invención se refiere a un UE para el restablecimiento de una conexión de RRC entre el UE y un eNB objetivo, para la optimización de CP CIoT. El UE comprende:
un procesador, y un producto de programa informático que almacena instrucciones que, cuando se ejecutan por medio del procesador, hacen que el UE:
reciba un mensaje de Restablecimiento de Conexión de RRC desde el eNB objetivo, incluyendo el mensaje de Restablecimiento de Conexión de RRC una señal de muestra de autenticación de DL que ha sido generada por una MME y que ha tenido una clave de integridad de NAS y una identidad de la célula objetivo como entrada, y autentique la señal de muestra de autenticación de DL recibida.
Un quinto aspecto se refiere a un eNB objetivo para el restablecimiento de una conexión de RRC entre un UE y el eNB objetivo, para la optimización de CP CIoT. El eNB objetivo comprende:
un procesador, y
un producto de programa informático que almacena instrucciones que, cuando son ejecutadas por el procesador, hacen que el eNB:
reciba, desde una MME, un mensaje que incluye una señal de muestra de autenticación de DL que ha sido generada por la MME, en donde la señal de muestra de autenticación de DL ha sido generada con una clave de integridad de NAS y una identidad de la célula objetivo como entrada, y
envíe un mensaje de Restablecimiento de Conexión de RRC al UE, incluyendo el mensaje de Restablecimiento de Conexión de RRC la señal de muestra de autenticación de DL.
Un sexto aspecto se refiere a un una MME para restablecer una conexión de RRC entre un UE y un eNB objetivo, para la optimización de CP CIoT. El MME comprende:
un procesador, y
un producto de programa informático que almacena instrucciones que, cuando se ejecutan por medio del procesador, hacen que el MME:
genere una señal de muestra de autenticación de DL con una clave de integridad de NAS y una identidad de célula objetivo como entrada; y
envíe un mensaje que incluye la señal de muestra de autenticación de DL al eNB objetivo.
Un séptimo aspecto se refiere a un programa informáti
objetivo, para la optimización de CP CIoT. El programa informático comprende un código de programa informático que, cuando se ejecuta en la UE, hace que la UE:
reciba un mensaje de restablecimiento de la conexión RRC del eNB objetivo, el mensaje de restablecimiento de la conexión RRC incluye una señal de muestra de autenticación de DL que se ha generado mediante un MME y que tiene una clave de integridad de estrato NAS y una identidad de la célula objetivo como entrada; y autentique la señal de muestra de autenticación DL recibida.
Un octavo aspecto se refiere a un programa informático para el restablecimiento de una conexión de RRC entre un UE y un eNB objetivo, para la optimización de CP CIoT. El programa informático comprende un código de programa informático que, cuando se ejecuta en el eNB objetivo, hace que el eNB:
reciba, desde una MME, un mensaje que incluye una señal de muestra de autenticación de DL que ha sido generada por la MME, en donde la señal de muestra de autenticación de DL ha sido generada con una clave de integridad de NAS y una identidad de la célula objetivo como entrada, y
envíe un mensaje de Restablecimiento de Conexión de RRC al UE, incluyendo el mensaje de Restablecimiento de Conexión de RRC la señal de muestra de autenticación de DL.
Un noveno aspecto se refiere a un programa informático para el restablecimiento de una conexión de RRC entre un UE y un eNB objetivo, para la optimización de CP CIoT. El programa informático comprende un código de programa informático que, cuando se ejecuta en una MME, provoca que la MME:
genere una señal de muestra de autenticación de DL con una clave de integridad de NAS y una identidad de la célula objetivo como entrada, y
envíe un mensaje que incluye la señal de muestra de autenticación de DL generada al eNB objetivo.
Breve descripción de los dibujos
Ahora se va a describir la invención, a título de ejemplo, con referencia a los dibujos que se acompañan, en los que:
La Figura 1 muestra esquemáticamente señalización del principio de DoNAS;
la Figura 2 ilustra esquemáticamente un entorno en el que pueden ser aplicadas las realizaciones presentadas en la presente descripción;
la Figura 3a muestra esquemáticamente señalización conforme a una parte de una realización presentada en la presente descripción;
la Figura 3b muestra esquemáticamente señalización conforme a una parte de una realización presentada en la presente descripción y que se inicia en la Figura 3a;
la Figura 4a muestra esquemáticamente señalización conforme a una parte de una realización presentada en la presente descripción;
la Figura 4b muestra esquemáticamente señalización conforme a una parte de una realización presentada en la presente descripción y que se inicia en la Figura 4a;
la Figura 5 muestra esquemáticamente señalización conforme a una realización presentada en la presente memoria;
la Figura 6 muestra esquemáticamente señalización conforme a una realización presentada en la presente descripción;
las Figuras 7A-7D son diagramas de flujo que ilustran métodos conforme a realizaciones presentadas en la presente descripción;
las Figuras 8-11 son diagramas esquemáticos que ilustran algunos componentes de entidades presentadas en la presente memoria, y
las Figuras 12-15 son diagramas esquemáticos que muestran módulos funcionales de realizaciones presentadas en la presente descripción.
Descripción detallada
Ahora se va a describir la invención de forma más detallada en lo que sigue, con referencia a los dibujos que se acompañan, en los que se han mostrado algunas realizaciones de la invención. La materia que se trata a continuación denominada, entre otros, con los términos “variante(s)” y “realización(es)” sirve para destacar y explicar las características reivindicadas. El alcance de la invención está definido en las reivindicaciones. Los números iguales se refieren a elementos iguales a través de la descripción.
El restablecimiento de conexión de Control de Recurso de Radio (RRC) y los procedimientos de suspensión/reanudación de conexión de RRC son soluciones existentes, que podrían ser candidatos para gestionar un fallo de radio enlace en caso de un caso de optimización Internet Celular de las Cosas (CIoT) de Plano de Control (CP). Ambas soluciones existentes citadas usan una señal de muestra de autenticación del Equipo de Usuario (UE) según se ha descrito en los antecedentes, para mostrar a un NodeB evolucionado (eNB) que un UE 1 genuino desea restablecer o reanudar una conexión de RRC. Adicionalmente, se usan mensajes de RRC protegidos en cuanto a integridad en la dirección de enlace descendente (DL) para mostrar al UE 1 que éste se encuentra conectado a un eNB genuino. Sin embargo, esas soluciones están basadas en la existencia de seguridad de Estrato de Acceso (AS) (especialmente, seguridad de RRC), pero la seguridad de AS y la seguridad de RRC no existen o no se usan para las optimizaciones de CIoT de CP. Por lo tanto, el restablecimiento de conexión de RRC y los procedimientos de suspensión/reanudación de conexión de RRC como tales, no son aceptables en cuanto a seguridad para ser usados en la gestión de movilidad en el CIoT de CP.
Una solución descrita en S3-161717 de contribución de 3GPP propone que una señal de muestra de autenticación podría estar basada en una nueva clave de integridad de RRC (denominada KeNB-RRC) que puede ser deducida tanto por el UE 1 como por la Entidad 4 de Gestión de Movilidad (MME), sin establecer seguridad de AS (incluyendo seguridad de RRC) entre el UE 1 y el eNB 2 fuente a través de un procedimiento de Comando de Modo de Seguridad (SMC) de AS , y la señal de muestra podría ser usada entre el UE 1 y el eNB 3 objetivo. Sin embargo, la solución descrita en S3-161717 de contribución de 3GPP está intentando resolver el problema de cómo mostrar al eNB que un UE 1 genuino desea restablecer una conexión de RRC. El problema de cómo mostrar al UE 1 que está conectado a un eNB genuino, no está contemplado.
En ausencia de seguridad de AS, y por consiguiente la ausencia de protección de integridad de mensajes de RRC de DL desde el eNB hasta el UE, en el contexto de movilidad de CIoT de CP, no existe actualmente ninguna manera de mostrar al UE que está conectado a un eNB genuino. Para mitigar ese problema, se ha presentado el uso de una señal de muestra de autenticación en la dirección de DL desde la red hasta el UE. La señal de muestra de autenticación puede ser generada y enviada por la MME, por el eNB fuente o por el eNB objetivo. La señal de muestra de autenticación de DL puede ser calculada usando las claves de NAS o de AS (aunque esto último no está dentro del alcance de las reivindicaciones la presente solicitud), dependiendo de la entidad que la esté enviando. Se han identificado los casos siguientes:
Una señal de muestra de autenticación de DL se envía siempre al UE a través del eNB objetivo.
Las cuatro variantes de soluciones que siguen muestran cómo se puede conseguir esto.
1 a. La señal de muestra de autenticación de DL se envía desde el eNB fuente a través del eNB objetivo hasta el UE y se comprueba por medio del UE con una clave de AS. Alternativamente, el eNB objetivo calcula la señal de muestra con claves de KrrC_int recibidas desde el eNB fuente. Esta variante no está dentro del alcance de las reivindicaciones de la presente solicitud.
1b. La señal de muestra de autenticación de DL se envía desde la MME a través del eNB fuente y del eNB objetivo, hasta el UE y se comprueba por medio del UE con una clave de NAS.
2a. La señal de muestra de autenticación de DL se envía desde la MME en un mensaje de Acuse de Recibo de Conmutación de Ruta a través del eNB objetivo hasta el UE, y el UE comprueba la señal de muestra de autenticación de DL con una clave de NAS.
2b. La señal de muestra de autenticación de DL se envía desde la MME en un nuevo mensaje a través del eNB objetivo hasta el UE y el UE comprueba la señal de muestra con una clave de NAS.
Cuando una comprobación realizada por el UE que está conectado a un eNB genuino esté basada en una señal de muestra de autenticación de DL, no existe ninguna necesidad de establecer claves de AS en absoluto. Con ello, se puede evitar la generación de claves de AS, lo que resulta beneficioso, puesto que las claves de AS podrían, en su caso, tener que ser generadas solamente a los efectos del restablecimiento de la conexión de RRC y no ser usadas para nada más. Las claves de NAS podrían sin embargo ser utilizables para otros problemas de seguridad distintos de autenticar solamente el eNB. De manera más precisa, las claves de NAS han sido creadas en cualquier caso, puesto que existe un contexto de seguridad de NAS para un UE que envía datos a través de la NAS.
Cuando el UE experimenta un fallo de enlace de radio (RLF) durante una conexión de CIoT de CP (DoNAS), el UE trata de restablecer la conexión de RRC con otro eNB, véase la Figura 2.
La señal de muestra de autenticación de la red para su uso en CIoT de CP (indicada como MAC CIoT DL) es una señal de muestra que podrá ser usada para autenticación de la red, es decir, para mostrar al UE 1 que está conectado a un eNB 3 objetivo genuino.
La MAC CIoT DL según la invención reivindicada se calcula con lo siguiente como entrada:
- Clave de integridad de NAS (NAS-int., p. ej., KNASint). En otras variantes, aunque no se reivindican en esta solicitud, también puede ser una clave de integridad de AS o una clave deducida a partir de la clave de NAS-int o de integridad de AS (Krrc_int) o una clave deducida a partir de una cualquiera de esas claves. NAS-int está indicada, en muchas instancias a través del texto que sigue, como Key-MAC CIoT DL. El uso de una clave de NAS o de AS depende de si MAC CIoT DL es calculada por la MME 4 o por un eNB. Tras claves alternativas fuera del alcance de las reivindicaciones de la presente solicitud, son claves raíz para el NAS-int, p. ej., KASME en LTE y KAUSF, KSEAF y KAMF en sistemas de Nueva Radio, e
- Identidad de la célula objetivo (ID de célula).
Otras posibles entradas, que no son parte de la invención reivindicada son:
- Identidad de célula física de la célula fuente
- C-RNTI del UE en la célula fuente.
- constante (la constante permite la diferenciación de MAC CIoT de la ShortResumeMAC-I y de la ShortMAC-I o una MAC definida de otras formas).
- posiblemente una entrada al cálculo de MAC CIoT DL es una señal de muestra de autenticación de enlace ascendente, UL, denominada en la presente como MAC CIoT UL (enlace ascendente).
- un parámetro de refresco.
La entrada usada para el cálculo de la MAC CIoT DL será indicada como Input-MAC CIoT DL. La identidad de la célula objetivo puede, de ese modo, formar parte de la Input-MAC CIoT DL, pero la clave de integridad de NAS puede estar separada de la Input-MAC-CIoT DL recibida por el UE, dado que típicamente éste tiene ya la clave de integridad de NAS y ha usado la misma para el cálculo de la MAC CIoT UL.
La función usada para el cálculo de la MAC CIoT DL (indicada como Fun-MAC CIoT DL) puede ser la misma usada en el Anexo B.2 de TS 33.401 para restablecimiento de RRC y reanudación de RRC, es decir, un algoritmo de integridad en forma de un algoritmo de integridad NAS de 128 bits, el cual puede ser 128-EIA1, 128-EIA2 y 128-EIA3. La variante 1a ha sido ilustrada en las Figuras 3a y 3b, en donde MAC CIoT DL se envía desde el eNB fuente y se comprueba por medio del UE con una clave de AS (no comprendida dentro del alcance de las reivindicaciones de la solicitud) o mediante una clave de NAS.
Esta variante está basada en una negociación de algoritmo de AS a través del protocolo de NAS y la posterior comprobación de la señal de muestra de enlace ascendente denominada MAC CIoT UL en el eNB fuente. La variante comprende un mecanismo donde el eNB fuente, tras haber comprobado la MAC CIoT UL, genera una señal de muestra de enlace descendente denominada MAC CIoT DL. El eNB fuente envía la MAC CIoT DL al eNB objetivo en un mensaje de respuesta de contexto de UE X2. El eNB objetivo envía la MAC CIoT DL además al UE en un mensaje de RRC para comprobación de autenticación. Si la comprobación de la MAC CIoT DL tiene éxito, el UE sabe que está conectado a un eNB auténtico, y no a un eNB falso.
Las etapas 1 a 15 están definidas en las especificaciones de 3GPP actuales. El UE establece una conexión de RRC y envía datos a través de NAS, los cuales son reenviados desde MME a Puerta de Acceso de Servidor (S-GW)/Puerta de Acceso de Red de Datos por Paquetes (P-GW). En la etapa 15 ocurre un RLF. El RLF también puede ocurrir antes de que el UE haya recibido datos de DL.
Etapa 16. El UE inicia una conexión de RRC enviando un mensaje de Acceso Aleatorio a un eNB objetivo.
Etapa 17. El eNB objetivo responde con una Respuesta de Acceso Aleatorio al UE.
Etapa 18. El UE genera una señal de muestra de autenticación, MAC CIoT UL. La señal de muestra puede ser calculada de la forma siguiente: señal de muestra = f(PCI fuente, C-RNTI fuente, ID de Célula objetivo, clave de NAS, entrada de repetición), donde la clave de NAS es la actual clave de integridad de NAS, p. ej. KNASint, o es un derivado de la misma. f = función. Sin embargo, con respecto a esta variante 1a particular, la señal de muestra podría en cambio ser deducida por medio de una clave de AS en vez de la clave de NAS. La clave de AS puede ser una clave de integridad de AS, tal como KRRCint.
Etapa 19. El UE envía un mensaje de restablecimiento de conexión de RRC al eNB objetivo, p. ej., para optimización de EPS (Sistema de Paquetes Evolucionado) de IoT de CP. El mensaje incluye la MAC CIoT UL.
Etapa 20. El eNB objetivo envía un mensaje de solicitud de contexto de UE X2 al eNB fuente. El mensaje incluye la MAC CIoT UL.
Etapa 21. El eNB fuente comprueba si la MAC CIoT UL es auténtica.
Etapa 22. Si la autenticación tiene éxito, el eNB fuente genera MAC CIoT DL según se ha descrito con anterioridad usando Input-MAC CIoT DL y la Key-MAC CIoT DL, y el procesamiento continúa en la etapa 23. Si la autenticación falla, el eNB fuente envía una respuesta de contexto de UE X2 indicando el fallo. El fallo activará el eNB objetivo para que libere la conexión de RRC (no representada).
Etapa 23. El eNB fuente envía una respuesta de contexto de UE X2 al eNB objetivo. El mensaje incluye la MAC CIoT DL. El mensaje puede incluir además Input-MAC CIoT DL.
Etapa 24. El eNB objetivo envía un mensaje de restablecimiento de conexión de RRC al UE. El mensaje incluye la MAC CIoT DL. El mensaje puede incluir además Input-MAC CIoT DL.
Etapa 25. Tras la recepción del mensaje de restablecimiento de conexión de RRC, el UE autentica la MAC CIoT DL usando Input-MAC CIoT DL y la Key-MAC CIoT DL según se ha descrito con anterioridad.
Etapa 26A. Si la autenticación de MAC CIoT DL tiene éxito:
26A.1 El UE envía un mensaje de Restablecimiento de Conexión de RRC Completado, que opcionalmente contiende PDU de datos NAS, al eNB objetivo.
26A.2-26A.5. Estas etapas son procedimientos normales de conmutación de ruta y de modificación de portadora.
26A.6. El eNB objetivo dice ahora al eNB fuente que libere el contexto de UE enviando un mansaje X2 denominado Liberación de Contexto de UE.
Si la autenticación de la MAC CIoT DL de la etapa 25 falla, el UE puede realizar acciones tales como no enviar mensajes adicionales o hacer transición al modo RRC_CONNECTED para autenticar la red, etc.
La variante 1b ha sido ilustrada en las Figuras 4a-4b, en donde la MAC CIoT DL se envía desde la MME hasta el eNB fuente y desde el eNB fuente hasta el eNB objetivo y desde el eNB objetivo hasta el UE y a continuación se comprueba por medio del UE con una clave de NAS.
Éste es un ejemplo aplicable a una situación en la que ocurra un RLF, p. ej., durante el envío de datos NAS para optimizaciones de CIoT de CP.
Las etapas 1 a 18 son según están definidas en las especificaciones actuales de 3GPP.
Etapa 19. El UE envía un mensaje de RRC al eNB objetivo que incluye la MAC CIoT UL. El mensaje de RRC puede ser una solicitud de restablecimiento de conexión de RRC, una solicitud de reanudación de RRC o algún otro mensaje de RRC.
Etapa 20. El eNB objetivo envía un mensaje X2 al eNB fuente que incluye la MAC CIoT UL. El mensaje X2 puede ser un mensaje de extracción de contexto X2.
Etapa 21. El eNB fuente envía un mensaje S1 a la MME que incluye la MAC CIoT UL y la Input-MAC CIoT UL. Etapa 22. Tras la recepción de la MAC CIoT UL y de la Input-MAC CIoT UL, la MME verifica la MAC CIoT UL llevando a cabo el mismo cálculo que realizó el UE, y comparándola con la MAC CIoT UL recibida. Si la verificación tiene éxito, la MME genera MAC CIoT DL según se ha descrito con anterioridad, usando la Input-MAC CIoT DL y la Key-MAC CIoT DL y continúa el procesamiento en la etapa 23, en donde la MME envía un mensaje S1 indicando el éxito al eNB fuente y que incluye la MAC CIoT DL. Si la verificación no ha tenido éxito, la MME envía un mensaje S1 indicando el error al eNB fuente. El eNB fuente envía a continuación una respuesta de contexto de UE X2 indicando el fallo. El fallo activará el eNB objetivo para liberar la conexión de RRC (no representada).
Etapa 23. La MME envía un mensaje de respuesta de Comprobación S1 al eNB fuente indicando el éxito. El mensaje incluye la MAC CIoT DL. El mensaje puede incluir además Input-MAC CIoT DL.
Etapa 24. El eNB fuente envía una respuesta de contexto de UE al eNB objetivo. El mensaje incluye la MAC CIoT DL. El mensaje puede incluir además Input-MAC CIoT DL.
Etapa 25. El eNB objetivo envía un mensaje de restablecimiento de conexión de RRC al UE. El mensaje incluye la MAC CIoT DL. El mensaje puede incluir además Input-MAC CIoT DL.
Etapa 26. Tras la recepción del mensaje de restablecimiento de conexión de RRC, el UE autentica la MAC CIoT DL usando Input-MAC CIoT DL y la Key-MAC CIoT DL según se ha descrito con anterioridad.
Etapa 27A. Si la autenticación de la MAC CIoT DL ha tenido éxito:
27A.1. El UE envía un mensaje de Restablecimiento de Conexión de RRC Completado, que opcionalmente contiene PDU de datos NAS, al eNB objetivo.
27A.2-27A.5. Estas etapas son procedimientos normales de conmutación de ruta y de modificación de portadora.
27A.6. El eNB objetivo dice ahora al eNB fuente que libere el contexto de UE enviando un mensaje X2 denominado Liberación de Contexto de UE.
Si la autenticación de la MAC CIoT DL en la etapa 25 falla, entonces el UE puede realizar acciones tales como no enviar mensajes adicionales o hacer transición al modo RRC_CONNECTED para autenticar la red, etc.
La variante 2a ha sido ilustrada en la Figura 5, en donde la MAC CIoT DL se envía desde la MME al eNB objetivo en un mensaje de Acuse de Recibo de Solicitud de Conmutación de Ruta S1AP. La MAC CIoT DL se envía desde el eNB objetivo hasta el UE.
Esta variante se basa en un mensaje S1AP existente denominado Acuse de Recibo de Solicitud de Conmutación de Ruta que se envía desde la MME hasta el eNB objetivo. El Acuse de Recibo de Solicitud de Conmutación de Ruta se modifica para que sea capaz de portar la MAC CIoT DL y la Input-MAC CIoT DL. Resultará obvio para los expertos en la materia que el orden de las etapas, los mensajes y los campos podrá ser alterado; los mensajes combinados; los campos situados en diferentes mensajes, etc., para conseguir el mismo efecto.
Las etapas 1-17 son las mismas que las descritas con anterioridad en relación con la Figura 3a.
Las etapas 18-19 son también iguales que las descritas con anterioridad en relación con la Figura 3a, pero éstas se han mostrado también en la Figura 5 para la integridad del procedimiento de Restablecimiento de Conexión de RRC. Etapa 20. El eNB objetivo solicita al eNB fuente que envíe el contexto del UE. Un mensaje X2 existente denominado Recuperar Solicitud de Contexto de UE puede ser adaptado según sea necesario (p. ej., usando ReestabUE-Identity en vez de ResumeIdentity).
Etapa 21. El eNB fuente envía el contexto del UE al eNB objetivo. Un mensaje X2 existente denominado Recuperar Respuesta de Contexto de UE puede ser adaptado según sea necesario.
Etapa 22. El eNB objetivo envía un mensaje de Restablecimiento de Conexión de RRC al UE.
Etapa 23. El UE envía un mensaje de Restablecimiento de Conexión de RRC Completado, que opcionalmente contiene PDU (Unidad de Datos de Protocolo) de datos NAS, al eNB objetivo.
Etapa 24. El eNB objetivo envía una Solicitud de Conmutación de Ruta a la MME. En la Solicitud de Conmutación de Ruta, el eNB objetivo incluye MAC CIoT UL e Input-MAC CIoT UL. Según se ha comentado con anterioridad, la Input-MAC CIoT UL puede incluir la identidad de la célula objetivo. El eNB objetivo recibió la MAC CIoT UL en la Etapa 19.
La Input-MAC CIoT UL puede incluir información que el eNB objetivo recibió en la etapa 19 y/o en la etapa 21, y/o información propia del eNB objetivo. La Solicitud de Conmutación de Ruta puede contener la información del UE que permite que la MME identifique el contexto del UE en la MME. Esa información del UE se denomina en la actualidad “ID de MME UE S1AP Fuente”, que el eNB objetivo está capacitado para proporcionar por el eNB a partir de la información que éste recibió en la etapa 23.
Etapa 25. La MME autentica la MAC CIoT UL, p. ej., usando la Input-MAC CIoT UL y la Key-MAC CIoT UL como entrada a la Fun-MAC CIoT UL. La Key-MAC CIoT UL es, una realización, igual que la Key-MAC CIoT DL, es decir, la clave de integridad de NAS que puede ser deducida separadamente por la MME y por el UE, respectivamente, en base a KASME, como conocen los expertos en la materia.
En lo que sigue, por motivos de simplicidad, solamente se van a describir con detalle las etapas relevantes para la presente solución, las cuales son, en caso de que la autenticación en la etapa 25 tenga éxito:
Etapa 26. La MME genera MAC CIoT DL según se ha descrito con anterioridad, usando la Input-MAC CIoT DL y la Key-MAC CIoT DL. Algunos elementos de la Input-MAC CIoT DL, al igual que la identificad de la célula (ID de célula) objetivo, pueden ser obtenidos a partir de la Input-MAC CIoT UL.
Etapa 27. La MME envía un mensaje S1, mensaje de Acuse de Recibo de Solicitud de Conmutación de Ruta, indicando éxito al eNB objetivo, y el mensaje de Acuse de Recibo de Solicitud de Conmutación de Ruta está adaptado para que incluya MAC CIoT DL e Input-MAC CIoT DL.
Etapa 28. El eNB objetivo sabe ahora que la MAC CIoT UL enviada por el UE y mencionada en etapas anteriores, es auténtica. El eNB objetivo envía la MAC CIoT DL y la Input-MAC CIoT DL al UE en un mensaje de RRC, por ejemplo poniéndolas en el campo de DedicatedInfoNAS del mensaje de DLInformationTransfer del procedimiento de T ransferencia de Información de DL de RRC. Se puede introducir también una nueva clase de procedimiento de RRC para este propósito particular de transporte de la MAC CIoT DL hasta el UE, p. ej., Confirmación de Restablecimiento de RRC.
Etapa 29. El UE autentica la MAC CIoT DL usando la Input-MAC CIoT DL y la Key-MAC CIoT DL como entrada a la Fun-MAC CIoT DL.
Si la autenticación de la MAC CIoT DL en la etapa 27 falla, entonces el UE puede realizar acciones tales como no enviar mensajes adicionales o hacer transición al modo de RRC_CONNECTED para autenticar la red, etc.
La variante 2b ha sido ilustrada en la Figura 6, en donde la MAC CIoT DL se envía desde la MME hasta el eNB objetivo en un nuevo mensaje S1AP y desde el eNB objetivo hasta el UE.
Esta variante se basa en un nuevo mensaje S1AP (indicado como Comprobar Solicitud de MAC) que se envía desde el eNB objetivo hasta la MME. El mensaje de Comprobar Solicitud de MAC está capacitado para transportar la MAC CIoT UL y la Input-MAC CIoT UL. De forma similar, nuevos mensajes S1AP, indicados como Comprobar Acuse de Recibo de MAC y Comprobar Fallo de MAC, que se envían desde la MME hasta el eNB objetivo, son usados para indicar respectivamente que la MAC CIoT UL era auténtica o no era auténtica. El nuevo mensaje S1AP de Comprobar Acuse de Recibo de MAC porta la MAC CIoT DL y la Input-MAC CIoT DL desde la MME hasta el eNB objetivo. El eNB objetivo incluye la MAC CIoT DL y la Input-MAC CIoT DL para el UE en un mensaje de Restablecimiento de Conexión de RRC. Resultará obvio para un experto en la materia apreciar que el orden de las etapas, ,mensajes, campos, podrá ser alterado; los mensajes combinados; los campos situados en diferentes mensajes, etc., para conseguir los mismos efectos.
Las etapas 1-17 son iguales que las discutidas con anterioridad en relación con la Figura 3.
Las etapas 18-19 son también iguales que las discutidas con anterioridad, pero han sido ilustradas por razones de integridad del procedimiento de Restablecimiento de Conexión de RRC.
Etapa 20. El eNB objetivo solicita al eNB fuente que envíe el contexto del UE. Un mensaje X2 existente denominado Recuperar Solicitud de Contexto de UE puede ser adaptado según sea necesario, p. ej., usando ReestabUE-Identitiy en vez de ResumeIdentity.
Etapa 21. El eNB fuente envía el contexto del UE al eNB objetivo. Un mensaje X2 existente denominado Recuperar Respuesta de Contexto de UE puede ser adaptado según sea necesario. El contexto del UE dice al eNB objetivo la MME correspondiente en la que el UE está registrado.
Etapa 22. El eNB objetivo envía un mensaje en forma de Comprobar Solicitud de MAC a la MME identificada en la etapa 21. En el mensaje de Comprobar Solicitud de MAC, el eNB objetivo incluye MAC CIoT UL e Input-MAC CIoT UL. El eNB objetivo recibió la MAC CIoT UL en la etapa 19. La Input-MAC CIoT UL puede incluir información que el eNB objetivo recibió en la etapa 19 y/o en la etapa 21 y/o la información propia del eNB objetivo. Tal información incluida en la Input-MAC CIoT UL puede ser la identidad de la célula objetivo, que ha sido por tanto usada como entrada junto con al menos la clave de integridad de NAS para generar la señal de muestra MAC CIoT UL de autenticación de UL. El mensaje de Comprobar Solicitud de MAC puede contener también información del UE que permita que la MME identifique el contexto del UE en la MME. Esa información del UE puede ser, por ejemplo, el ID de MME UE S1AP que el eNB objetivo recibió desde el eNB fuente en la etapa 21.
Etapa 23. La MME autentica la MAC CIoT UL usando la Input-MAC CIoT UL y la Key-MAC CIoT UL (p. ej., la misma clave de integridad de NAS usada como Key-MAC CIoT DL) como entrada a la Fun-MAC CIoT UL. En otras palabras, el resultado de la Fun-MAC CIoT UL se compara con la MAC CIoT UL recibida para una verificación de la MAC CIoT UL recibida.
En lo que sigue, por motivos de simplicidad, solamente se describen con más detalle las etapas relevantes para esta variante, las cuales son, si la autenticación de la etapa 23 ha tenido éxito:
Etapa 24. La MME genera MAC CIoT DL según se ha descrito con anterioridad, usando la Input-MAC CIoT DL y la Key-MAC CIoT DL. Algunos elementos de la Input-MAC CIoT DL, como la identidad de la célula objetivo, pueden ser obtenidos a partir de la Input-MAC CIoT UL. La MME envía un mensaje S1 (mensaje de Comprobar Acuse de Recibo de MAC) indicando el éxito al eNB objetivo e incluye MAC CIoT DL e Input-MAC CIoT DL.
Etapa 25. La MME envía un mensaje de Comprobar Acuse de Recibo de Solicitud de MAC al eNB objetivo. El mensaje incluye la MAC CIoT DL, y opcionalmente también la Input-MAC CIoT DL. El eNB objetivo sabe ahora que la MAC CIoT UL mencionada en las etapas anteriores, es auténtica.
Etapa 26. El eNB objetivo envía un mensaje de Restablecimiento de Conexión de RRC al UE. Este mensaje incluye la Ma c CIoT DL y puede incluir la Input-MAC CIoT DL.
Etapa 27. El UE autentica la MAC CIoT DL usando la Input-CIoT DL y la Key-MAC CIoT DL como entrada a la Fun-MAC CIoT DL.
Etapa 28. Si la autenticación de la MAC CIoT DL en la etapa 27 tiene éxito, entonces el UE envía un mensaje de Restablecimiento de Conexión de RRC Completado, que opcionalmente contiene la PDU de datos NAS al eNB objetivo.
Si la autenticación de la MAC CIoT DL en la etapa 27 falla, entonces el UE puede realizar algunas acciones tales como no enviar mensajes adicionales o hacer una transición al modo de RRC_CONNECTED para autenticar la red, etc.
Un método, según una realización, para el restablecimiento de una conexión de RRC entre un UE y un eNB objetivo, se presenta con referencia a la Figura 7A. El método se lleva a cabo por medio del UE 1 y comprende recibir S100 un mensaje de Restablecimiento de Conexión de RRC desde un eNB 3 objetivo, p. ej., para optimización de loT de CP, incluyendo el mensaje de Restablecimiento de Conexión de RRC una señal de muestra de autenticación de DL que ha sido generada por la MME 4 y que ha tenido una clave de integridad de NAS como entrada, y autenticar S110 la señal de muestra de autenticación de DL recibida.
El mensaje de Restablecimiento de Conexión de RRC que incluye la señal de muestra de autenticación de DL puede también incluir opcionalmente una Input-MAC CIoT DL y la señal de muestra de autenticación de DL recibida puede ser autenticada usando la Input-MAC CIoT DL recibida y la clave de integridad de NAS.
El mensaje de RRC puede ser un mensaje de Transferencia de Información de DL de RRC que incluya MAC CIoT DL y opcionalmente Input-MAC CIoT DL, y la MAC CIoT DL recibida puede ser autenticada usando Input-MAC CIoT DL y Key-MAC CIoT DL.
En una etapa S80 opcional anterior a S100, el UE calcula una señal de muestra de autenticación de UL (mencionada como AT de UL en la Figura 7A) con la clave de integridad de NAS como entrada, y en una etapa S90 opcional envía una solicitud de restablecimiento de conexión de RRC que incluye la señal de muestra de autenticación de UL al eNB 3 objetivo. La señal de muestra de autenticación de UL puede ser calculada con la identidad de la célula objetivo como entrada, y la identidad de la célula objetivo puede estar incluida en la solicitud de restablecimiento de conexión de RRC, p. ej., como parte de una Input-MAC UL.
Un método, según una realización, para restablecer una conexión de RRC entre un UE y un eNB objetivo, p. ej. para optimización de IoT de CP, ha sido ilustrado con referencia a la Figura 7B. El método se lleva a cabo por medio del eNB 3 objetivo y comprende recibir S300, desde la MME 4, un mensaje que incluye una señal de muestra de autenticación de DL que ha sido generada por la MME, en donde la señal de muestra de autenticación de DL ha sido generada con una clave de integridad de Estrato de No Acceso como entrada, y enviar S310 un mensaje de Restablecimiento de Conexión de RRC al UE 1, incluyendo el mensaje de Restablecimiento de Conexión de RRC la señal de muestra de autenticación de DL.
En una etapa S280 opcional, anterior a la S300, el eNB objetivo recibe desde el UE 1, una solicitud de restablecimiento de conexión de RRC que incluye una señal de muestra de autenticación de UL, en donde la señal de muestra de autenticación de UL ha sido calculada por el UE 1 con la clave de integridad de NAS como entrada. La señal de muestra de autenticación de UL, en una realización junto con la Input-MAC CIoT UL que incluye la identidad de la célula objetivo. En una etapa S290 opcional, anterior a la S300, el eNB objetivo envía/reenvía la señal de muestra de autenticación de UL a la MME 4, opcionalmente con la Input-MAC CIoT UL que incluye la identidad de la célula objetivo.
El mensaje de Restablecimiento de Conexión de RRC enviado puede incluir una Input-MAC CIoT DL.
El mensaje recibido puede ser un mensaje de Acuse de Recibo de Solicitud de Conmutación de Ruta que incluye Input-MAC CIoT DL.
El mensaje recibido puede ser un mensaje de Comprobar Acuse de Recibo de MAC que incluye una Input-MAC CIoT DL. Un método, según una realización, para restablecer una conexión de RRC entre un UE y un eNB objetivo, p. ej., para optimización de IoT de CP, ha sido presentado con referencia a la Figura 7C. El método se lleva a cabo en un eNB 2 fuente y comprende obtener S200 una señal de muestra de autenticación de DL que ha sido generada con una clave de integridad de NAS como entrada, y enviar S210 un mensaje de respuesta a un eNB 3 objetivo, incluyendo el mensaje de respuesta la señal de muestra de autenticación de DL obtenida.
La obtención S200 puede comprender generar la señal de muestra de autenticación de DL, o recibir un mensaje de Comprobar respuesta de S1 desde una MME 4, incluyendo el mensaje de Comprobar respuesta S1 recibido la señal de muestra de autenticación de DL y opcionalmente también la Input-MAC CIoT DL.
El mensaje de respuesta puede ser un mensaje de respuesta de contexto de UE X2.
Un método, según una realización, para restablecer una conexión de RRC entre un UE y un eNB objetivo, p. ej., para optimización de IoT de CP, ha sido presentado con referencia a la Figura 7D. El método se lleva a cabo por medio de la MME 4 y comprende generar S400 una señal de muestra de autenticación de DL con una clave de integridad de NAS como entrada, y enviar S410 un mensaje que incluye la señal de muestra de autenticación de DL generada al eNB 3 objetivo. La señal de muestra de autenticación de Dl puede ser generada también con la identidad de la célula objetivo como entrada.
En una etapa S380 opcional, anterior a la S400, la MME recibe una señal de muestra de autenticación de UL desde el eNB 3 objetivo, habiendo sido dicha señal de muestra de autenticación de UL generada por el UE 1 con la clave de integridad de NAS como entrada, y en una etapa S390 opcional verifica la señal de muestra de autenticación de UL, p. ej., calculando una segunda señal de muestra de autenticación de UL de la misma manera que lo hizo el UE (p. ej., con la clave de integridad de NAS y con la identidad de la célula objetivo como entrada) y comparando a continuación la segunda señal de muestra de autenticación de UL con la recibida desde el eNB objetivo.
El mensaje puede ser un mensaje de Acuse de Recibo de Solicitud de Conmutación de Ruta e incluye Input-MAC CIoT DL.
El mensaje puede ser un mensaje de Comprobar Acuse de Recibo de MAC que incluye Input-MAC CIoT DL.
Un UE 1 según una realización, para restablecer una conexión de RRC entre el UE 1 y el eNB 3 objetivo, ha sido presentado con referencia a la Figura 8. El UE 1 comprende un procesador 10 y un producto de programa informático. El producto de programa informático almacena instrucciones que, cuando son ejecutadas por el procesador, provocan que el UE reciba un mensaje de Restablecimiento de Conexión de RRC desde un eNB 3 objetivo, incluyendo el mensaje de Restablecimiento de Conexión de RRC una señal de muestra de autenticación de DL que ha sido generada por la MME 4 y que ha tenido una clave de integridad de NAS como entrada, y que autentique la señal de muestra de autenticación de DL recibida.
El mensaje de Restablecimiento de Conexión de RRC puede incluir opcionalmente Input-MAC CIoT DL, y la señal de muestra de autenticación de DL recibida puede ser autenticada usando Input-MAC CIoT DL y la clave de integridad de NAS.
Un eNB fuente, según una realización, para restablecer una conexión de RRC entre un UE 1 y un eNB 3 objetivo, se ha presentado con referencia a la Figura 9. El eNB 2 fuente comprende un procesador 20 y un producto de programa informático. El producto de programa informático almacena instrucciones que, cuando son ejecutadas por el procesador, provocan que el eNB fuente obtenga una señal de muestra de autenticación de DL que ha sido generada con una clave de integridad de NAS como entrada, y envíe un mensaje de respuesta al eNB 3 objetivo, incluyendo el mensaje de respuesta la señal de muestra de autenticación de DL obtenida.
El mensaje de respuesta puede ser un mensaje de respuesta de Contexto de UE X2.
Un eNB objetivo, según una realización, para restablecer una conexión de RRC entre un UE 1 y un eNB 3 objetivo, ha sido presentado con referencia a la Figura 10. El eNB 3 objetivo comprende un procesador 30 y un producto de programa informático. El producto de programa informático almacena instrucciones que, cuando son ejecutadas por el procesador, provocan que el eNB objetivo reciba desde la MME 4, un mensaje que incluye una señal de muestra de autenticación de DL que ha sido generada por la MME 4, en donde la señal de muestra de autenticación de DL ha sido generada con una clave de integridad de NAS como entrada, y envíe un mensaje de Restablecimiento de Conexión de RRC a un UE 1, incluyendo el mensaje de Restablecimiento de Conexión de RRC la señal de muestra de autenticación de DL. La señal de muestra de autenticación de DL ha sido calculada, en una realización, por medio de la MME 4 con una identidad de la célula objetivo como entrada.
El mensaje de Restablecimiento de Conexión de RRC enviado incluye opcionalmente Input-MAC CIoT DL, la cual puede incluir la identidad de la célula objetivo.
El mensaje recibido puede ser un mensaje de Acuse de Recibo de Solicitud de Conmutación de Ruta que incluya la Input-MAC CIoT DL.
El mensaje recibido puede ser un mensaje de Comprobar Acuse de Recibo de MAC que incluya Input-MAC CIoT DL.
Una MME, según una realización, para restablecer una conexión de RRC entre un UE 1 y un eNB 3 objetivo, ha sido presentada con referencia a la Figura 11. La MME 4 comprende un procesador 40 y un producto de programa informático. El producto de programa informático almacena instrucciones que, cuando son ejecutadas por el procesador, provocan que la MME genere una señal de muestra de autenticación de DL con una clave de integridad de NAS como entrada, y envíe un mensaje que incluye la señal de muestra de autenticación de DL generada al eNB 3 objetivo.
El mensaje puede ser un mensaje de Acuse de Recibo de Solicitud de Conmutación de Ruta, incluyendo el mensaje una Input-MAC CIoT DL.
El mensaje puede ser un mensaje de Comprobar Acuse de Recibo de MAC, incluyendo el mensaje la Input-MAC CIoT DL.
La Figura 8 es un diagrama esquemático que muestra algunos componentes del UE 1. El procesador 10 puede ser proporcionado con el uso de cualquier combinación de una o más de entre una unidad central de proceso, CPU, apropiada, un multiprocesador, microcontrolador, procesador de señal digital, DSP, circuito integrado específico de la aplicación, etc., capacitados para ejecutar instrucciones de software de un programa informático 14 almacenado en una memoria. La memoria puede ser considerada, por lo tanto, como que es el, o forma parte del, producto 12 de programa informático. El procesador 10 puede estar configurado para ejecutar métodos descritos en la presente memoria con referencia a la Figura 7A.
La memoria puede ser cualquier combinación de memoria de lectura y escritura, RAM, y de memoria de sólo lectura, ROM. La memoria puede comprender también almacenaje persistente, la cual puede ser, por ejemplo, una sola o una combinación de memoria magnética, memoria óptica, memoria de estado sólido o incluso memoria montada remotamente.
Un segundo producto 13 de programa informático en forma de memoria de datos puede ser proporcionado también, p. ej., para lectura y/o almacenaje de datos durante la ejecución de instrucciones de software en el procesador 10. La memoria de datos puede ser cualquier combinación de memoria de lectura y escritura, RAM, y de memoria de sólo lectura, ROM, y también puede comprender almacenaje persistente, la cual puede ser, por ejemplo, una sola o una combinación de memoria magnética, memoria óptica, memoria de estado sólido o incluso memoria montada remotamente. La memoria de datos puede contener, p. ej., otras instrucciones 15 de software, para mejorar la funcionalidad para el UE 1.
El UE 1 puede comprender además una interfaz 11 de entrada/salida (E/S) que incluya, p. ej., una interfaz de usuario. El UE 1 puede comprender además un receptor configurado para recibir señalización desde otros nodos, y un transmisor configurado para transmitir señalización a otros nodos (no representados). Otros componentes del UE 1 han sido omitidos con el fin de no oscurecer los conceptos que se presentan en la presente memoria.
La Figura 12 es un diagrama esquemático que muestra bloques funcionales del UE 1. Los módulos pueden ser implementados como únicamente instrucciones de software tal como un programa informático que se ejecuta en el servidor caché, o como únicamente hardware, tal como circuitos integrados específicos de la aplicación, matrices de puerta programable en campo, componentes lógicos discretos, transceptores, etc., o como una combinación de los mismos. En una realización alternativa, algunos de los bloques funcionales pueden ser implementados mediante software y otros mediante hardware. Los módulos corresponden a las etapas de los métodos ilustrados en la Figura 7A, comprendiendo una unidad 60 de gestor de determinación y una unidad 61 de gestor de comunicación. En las realizaciones en las que uno o más de los módulos están implementados por un programa informático, se comprenderá que esos módulos no correspondan necesariamente a módulos de proceso, sino que pueden estar escritos a modo instrucciones conforme a un lenguaje de programación en el que éstos podrían estar implementados, dado que algunos lenguajes de programación no contienen típicamente módulos de proceso.
El gestor 60 de determinación está destinado a habilitar el restablecimiento de una conexión de RRC entre un UE y un eNB objetivo. Este módulo corresponde a la etapa de comprobación S110 de la Figura 7A, es decir, la autenticación de la señal de muestra de autenticación de DL recibida. Este módulo puede estar implementado, p. ej., por el procesador 10 de la Figura 8, cuando ejecuta el programa informático.
El gestor 61 de comunicación está destinado a habilitar el restablecimiento de una conexión de RRC entre un UE y un eNB objetivo. Este módulo corresponde a la etapa de recepción S100 de la Figura 7A. Este módulo puede estar implementado, p. ej., por el procesador 10 de la Figura 12, cuando ejecuta el programa informático.
La Figura 9 es un diagrama esquemático que muestra algunos componentes del eNB 2 fuente. El procesador 20 puede ser proporcionado usando cualquier combinación de una o más de entre una unidad central de proceso, CPU, adecuada, un multiprocesador, microcontrolador, procesador de señal digital, DSP, circuito integrado específico de la aplicación, etc., capacitado para ejecutar instrucciones de software de un programa informático 24 almacenado en una memoria. La memoria puede ser considerada, por lo tanto, como que es el, o como que forma parte del, producto 22 de programa informático. El procesador 20 puede estar configurado para ejecutar métodos descritos en la presente memoria con referencia a la Figura 7B.
La memoria puede ser cualquier combinación de memoria de lectura y escritura, RAM, y de memoria de sólo lectura, ROM. La memoria puede también comprender almacenaje persistente, la cual puede ser, por ejemplo, una sola o una combinación de memoria magnética, memoria óptica, memoria de estado sólido o incluso memoria montada remotamente.
Un segundo producto 23 de programa informático en forma de memoria de datos puede ser también proporcionado, p. ej., para la lectura y/o el almacenaje de datos durante la ejecución de instrucciones de software en el procesador 20. La memoria de datos puede ser cualquier combinación de memoria de lectura y escritura, RAM, y de memoria de sólo lectura, ROM, y también puede comprender almacenaje persistente, la cual puede ser, por ejemplo, una sola o una combinación de memoria magnética, memoria óptica, memoria de estado sólido o incluso memoria montada remotamente. La memoria de datos puede, p. ej., mantener otras instrucciones 25 de software, para mejorar la funcionalidad para el eNB 2 fuente.
El eNB 2 fuente puede comprender además una interfaz 21 de entrada/salida (E/S) que incluya, p. ej., una interfaz de usuario. El eNB 2 fuente puede comprender además un receptor configurado para recibir señalización desde otros nodos, y un transmisor configurado para transmitir señalización a otros nodos (no representados). Otros componentes del eNB 2 fuente han sido omitidos con el fin de no oscurecer los conceptos presentados en la presente memoria.
La Figura 13 es un diagrama esquemático que muestra bloques funcionales del eNB 2 fuente. Los módulos pueden ser implementados como únicamente instrucciones de software tal como un programa informático que se ejecuta en el servidor caché, o como únicamente hardware, tal como los circuitos integrados específicos de la aplicación, matrices de puerta programable en campo, componentes lógicos discretos, transceptores, etc., o como una combinación de los mismos. En una realización alternativa, algunos de los bloques funcionales pueden ser implementados mediante software y otros mediante hardware. Los módulos corresponden a las etapas de los métodos ilustrados en la Figura 7C, comprendiendo una unidad 70 de gestor de determinación y una unidad 71 de gestor de comunicación. En las realizaciones en las que uno o más de los módulos se han implementado mediante un programa informático, se podrá comprender que esos módulos no correspondan necesariamente a módulos de proceso, sino que pueden estar escritos a modo de instrucciones conforme a un lenguaje de programación en el que éstos puedan ser implementados, dado que algunos lenguajes de programación no contienen típicamente módulos de proceso.
El gestor 70 de determinación está destinado a habilitar el restablecimiento de una conexión de RRC entre un UE y un eNB objetivo. Este módulo corresponde a la etapa de obtención S200 de la Figura 7C. Este módulo puede ser implementado, p. ej., mediante el procesador 20 de la Figura 9, cuando ejecuta el programa informático.
El gestor 71 de comunicación está destinado a habilitar el restablecimiento de una conexión de RRC entre un UE y un eNB objetivo. Este módulo corresponde a la etapa de envío S210 de la Figura 7C. Este módulo puede ser implementado, p. ej., mediante el procesador 20 de la Figura 13, cuando ejecuta el programa informático.
La Figura 10 es un diagrama esquemático que muestra algunos componentes del eNB 3 objetivo. El procesador 30 puede ser proporcionado usando cualquier combinación de uno o más de entre una unidad central de proceso, CPU, adecuada, un multiprocesador, microcontrolador, procesador de señal digital, DSP, circuito integrado específico de la aplicación, etc., capaz de ejecutar instrucciones de software de un programa informático 34 almacenado en una memoria. La memoria puede ser, por tanto, considerada como que es el, o forma parte del, producto 32 de programa informático. El procesador 30 puede estar configurado para ejecutar métodos descritos en la presente memoria con referencia a la Figura 7C.
La memoria puede ser cualquier combinación de memoria de lectura y escritura, RAM, y de memoria de sólo lectura, ROM. La memoria puede también comprender almacenaje persistente, la cual puede ser, por ejemplo, una sola o una combinación de memoria magnética, memoria óptica, memoria de estado sólido o incluso memoria montada remotamente.
Un segundo producto 33 de programa informático en forma de una memoria de datos, puede ser también proporcionado, p. ej., para lectura y/o almacenaje de datos durante la ejecución de instrucciones de software en el procesador 30. La memoria de datos puede ser cualquier combinación de memoria de lectura y escritura, RAM, y de memoria de sólo lectura, ROM, y también puede comprender almacenaje persistente, la cual puede ser, por ejemplo, una sola o una combinación de memoria magnética, memoria óptica, memoria de estado sólido, o incluso memoria montada remotamente. La memoria de datos puede contener, por ejemplo, otras instrucciones 35 de software, para mejorar la funcionalidad para el eNB 3 objetivo.
El eNB 3 objetivo puede comprender además una interfaz 31 de entrada/salida (E/S) que incluya, p. ej., una interfaz de usuario. El eNB 3 objetivo puede comprender además un receptor configurado para recibir señalización desde otros nodos, y un transmisor configurado para transmitir señalización a otros nodos (no representados). Otros componentes del eNB 3 objetivo han sido omitidos con el fin de no oscurecer los conceptos presentados en la presente memoria.
La Figura 14 es un diagrama esquemático que muestra bloques funcionales del eNB 3 objetivo. Los módulos pueden ser implementados como únicamente instrucciones de software tal como un programa informático que se ejecute en el servidor caché, o como únicamente hardware, tal como circuitos integrados específicos de la aplicación, matrices de puerta programable en campo, componentes lógicos discretos, transceptores, etc., o como una combinación de los mismos. En una realización alternativa, algunos de los bloques funcionales pueden ser implementados mediante software y otros mediante hardware. Los módulos corresponden a las etapas de los métodos ilustrados en la Figura 7B, comprendiendo una unidad 80 de gestor de determinación y una unidad 81 de gestor de comunicación. En las realizaciones en las que uno o más de los módulos estén implementados por un programa informático, se comprenderá que esos módulos no correspondan necesariamente a módulos de proceso, sino que pueden estar escritos a modo de instrucciones conforme a un lenguaje de programación en el que éstos podrían estar implementados, dado que algunos lenguajes de programación no contienen típicamente módulos de proceso.
El gestor 81 de comunicación está destinado a habilitar el restablecimiento de una conexión de RRC entre un UE y un eNB objetivo. Este módulo corresponde a la etapa de recepción S300 y a la etapa de envío 310 de la Figura 7B. Este módulo puede ser implementado, p. ej., mediante el procesador 30 de la Figura 10, cuando ejecuta el programa informático.
La Figura 11 es un diagrama esquemático que muestra algunos componentes de la MME 4. El procesador 40 puede ser proporcionado usando cualquier combinación de una o más de entre una unidad central de proceso, CPU, adecuada, un multiprocesador, microcontrolador, procesador de señal digital, DSP, circuito integrado específico de la aplicación, etc., capacitado para ejecutar instrucciones de software de un programa informático 44 almacenado en una memoria. La memoria puede ser considerada, por lo tanto, como que es el, o forma parte del, producto 42 de programa informático. El procesador 40 puede estar configurado para ejecutar métodos descritos en la presente memoria con referencia a la Figura 7D.
La memoria puede ser cualquier combinación de memoria de lectura y escritura, RAM, y de memoria de sólo lectura, ROM. La memoria puede comprender también almacenaje persistente, la cual puede ser, por ejemplo, una sola o una combinación de memoria magnética, memoria óptica, memoria de estado sólido o incluso una memoria montada remotamente.
Un segundo producto 43 de programa informático en forma de una memoria de datos puede ser proporcionado también, p. ej., para lectura y/o almacenaje de datos durante la ejecución de instrucciones de software en el procesador 40. La memoria de datos puede ser cualquier combinación de memoria de lectura y escritura, RAM, y de memoria de sólo lectura, ROM, y puede comprender también almacenaje persistente, la cual puede ser, por ejemplo, una sola o una combinación de memoria magnética, memoria óptica, memoria de estado sólido o incluso una memoria montada remotamente. La memoria de datos puede contener, p. ej., otras instrucciones 45 de software, para mejorar la funcionalidad para la MME 4.
La MME 4 puede comprender además una interfaz 41 de entrada/salida (E/S) que incluya, p. ej., una interfaz de usuario. La MME 4 puede comprender además un receptor configurado para recibir señalización desde otros nodos, y un transmisor configurado para transmitir señalización a otros nodos (no representados). Otros componentes de la MME 4 han sido omitidos con el fin de no oscurecer los conceptos presentados en la presente memoria.
La Figura 15 es un diagrama esquemático que muestra bloques funcionales de la MME 4. Los módulos pueden ser implementados como 'únicamente instrucciones de software tal como un programa informático que se ejecuta en el servidor caché, o como únicamente hardware, tal como circuitos integrados específicos de la aplicación, matrices de puerta programable en campo, componentes lógicos discretos, transceptores, et., o como una combinación de los mismos. En una realización alternativa, algunos de los bloques funcionales pueden ser implementados por medio de software y otros por medio de hardware. Los módulos corresponden a las etapas de los métodos ilustrados en la Figura 7D, comprendiendo una unidad 90 de gestor de determinación y una unidad 91 de gestor de comunicación. En las realizaciones en las que uno o más de los módulos estén implementados por un programa informático, se comprenderá que esos módulos no correspondan necesariamente a módulos de proceso, sino que pueden estar escritos a modo de instrucciones conforme a un lenguaje de programación en el que éstos podrían estar implementados, puesto que algunos lenguajes de programación no contienen típicamente módulos de proceso.
El gestor 90 de determinación está destinado a habilitar el restablecimiento de una conexión de RRC entre un UE y un eNB objetivo. Este módulo corresponde a la etapa de generación 400 de la Figura 7D. Este módulo puede ser implementado, p. ej., por el procesador 40 de la Figura 11, cuando ejecuta el programa informático.
El gestor 91 de comunicación está destinado a habilitar el restablecimiento de una conexión de RRC entre un UE y un eNB objetivo. Este módulo corresponde a la etapa de envío S410 de la Figura 7D. Este módulo puede ser implementado, p. ej., por el procesador 40 de la Figura 11, cuando ejecuta el programa informático.
La invención ha sido principalmente descrita en lo que antecede con referencia a unas pocas realizaciones. Sin embargo, como podrán apreciar fácilmente los expertos en la materia, otras realizaciones distintas de las descritas con anterioridad son también posibles.

Claims (15)

REIVINDICACIONES
1. Un método para restablecer una conexión de Control de Recurso de Radio, RRC, entre un Equipo de Usuario (1), UE, y un NodeB evolucionado (3) objetivo, eNB objetivo, para la optimización de Internet Celular de las Cosas de Plano de Control siendo el método llevado a cabo por el UE (1), y comprendiendo:
recibir (S100) un mensaje de Restablecimiento de Conexión de RRC desde el eNB (3) objetivo, incluyendo el mensaje de Restablecimiento de Conexión de RRC una señal de muestra de autenticación de enlace descendente, DL, que ha sido generada por una Entidad (4) de Gestión de Movilidad y que ha tenido una clave de integridad de Estrato de No Acceso y una identidad de la célula objetivo como entrada, y
autenticar (S110) la señal de muestra de autenticación de DL recibida.
2. El método según la reivindicación 1, que comprende calcular una señal de muestra de autenticación de enlace ascendente, UL, con la clave de integridad de Estrato de No Acceso como entrada, y enviar una solicitud de restablecimiento de conexión de RRC que incluya la señal de muestra de autenticación de UL al eNB (3) objetivo.
3. El método según la reivindicación 2, en donde la señal de muestra de autenticación de UL se calcula con la identidad de la célula objetivo como entrada.
4. Un método para restablecer una conexión de Control de Recurso de Radio, RRC, entre un Equipo de Usuario (1), UE, y un NodeB evolucionado (3) objetivo, eNB objetivo, para la optimización de Internet Celular de las Cosas de Plano de Control, siendo el método llevado a cabo por el eNB (3) objetivo y comprendiendo:
recibir (S300), desde una Entidad (4) de Gestión de Movilidad, MME, un mensaje que incluye una señal de muestra de autenticación de enlace descendente, DL, que ha sido generada por la m Me (4), en donde la señal de muestra de autenticación de DL ha sido generada con una clave de integridad de Estrato de No Acceso y una identidad de la célula objetivo como entrada, y
enviar (S310) un mensaje de Restablecimiento de Conexión de RRC al UE (1), incluyendo el mensaje de Restablecimiento de Conexión de RRC la señal de muestra de autenticación de DL.
5. El método según la reivindicación 4, que comprende recibir desde el UE (1) una solicitud de restablecimiento de conexión de RRC que incluye una señal de muestra de autenticación de enlace ascendente, UL, en donde la señal de muestra de autenticación de UL ha sido calculada por el UE (1) con la clave de integridad de Estrato de No Acceso como entrada.
6. El método según la reivindicación 5, en donde la señal de muestra de autenticación de UL ha sido calculada por el UE (1) con la identidad de la célula objetivo como entrada.
7. Un método para restablecer una conexión de Control de Recurso de Radio, RRC, entre un Equipo de Usuario (1), UE, y un NodeB evolucionado (3) objetivo, eNB objetivo, para la optimización de Internet Celular de las Cosas de Plano de Control, siendo el método llevado a cabo por una Entidad (4) de Gestión de Movilidad, MME, y comprendiendo:
generar (S400) una señal de muestra de autenticación de enlace descendente, DL, con una clave de integridad de Estrato de No Acceso y una identidad de la célula objetivo como entrada, y
enviar (S410) un mensaje que incluya la señal de muestra de autenticación de DL generada al eNB (3) objetivo.
8. El método según la reivindicación 7, que comprende:
recibir una señal de muestra de autenticación de enlace ascendente, UL, desde el eNB objetivo, habiendo sido dicha señal de muestra de autenticación de UL generada por el UE (1) con la clave de integridad de Estrato de No Acceso como entrada, y
verificar la señal de muestra de autenticación de UL.
9. El método según la reivindicación 8, en donde la señal de muestra de autenticación de UL ha sido generada por el UE (1) con la identidad de la célula objetivo como entrada.
10. Un Equipo de Usuario (1), UE, para restablecer una conexión de Control de Recurso de Radio, RRC, entre el UE (1) y un NodeB evolucionado (3) objetivo, eNB objetivo, para la optimización de Internet Celular de las Cosas de Plano de Control, comprendiendo el UE (1):
un procesador (10), y
un producto (12, 13) de programa informático que almacena instrucciones que, cuando son ejecutadas por el procesador, hacen que el UE:
reciba un mensaje de Restablecimiento de Conexión de RRC desde el eNB (3) objetivo, incluyendo el mensaje de Restablecimiento de Conexión de RRC una señal de muestra de autenticación de enlace descendente, DL, que ha sido generada por una Entidad (4) de Gestión de Movilidad y que ha tenido una clave de integridad de Estrato de No Acceso y una identidad de la célula objetivo como entrada, y
autentique la señal de muestra de autenticación de DL recibida.
11. Un NodeB evolucionado (3) objetivo, eNB objetivo, para restablecer una conexión de Control de Recurso de Radio, RRC, entre un Equipo de Usuario (1), UE, y el eNB objetivo, para la optimización de Internet Celular de las Cosas de Plano de Control, el eNB (3) objetivo comprende:
un procesador (30), y
un producto (32, 33) de programa informático que almacena instrucciones que, cuando son ejecutadas por el procesador, provocan que el eNB objetivo:
reciba, desde una Entidad (4) de Gestión de Movilidad, MME, un mensaje que incluye una señal de muestra de autenticación de enlace descendente, DL, que ha sido generada por la MME (4), en donde la señal de muestra de autenticación de DL ha sido generada con una clave de integridad de Estrato de No Acceso y una identidad de la célula objetivo como entrada, y
envíe un mensaje de Restablecimiento de Conexión de RRC al UE (1), incluyendo el mensaje de Restablecimiento de Conexión de RRC la señal de muestra de autenticación de DL.
12. Una Entidad (4) de Gestión de Movilidad, MME, para restablecer una conexión de Control de Recurso de Radio, RRC, entre un Equipo de Usuario (1), UE, y un NodeB evolucionado (3) objetivo, eNB objetivo, para la optimización de Internet Celular de las Cosas de Plano de Control, comprendiendo la MME (4):
un procesador (40), y
un producto (42, 43) de programa informático que almacena instrucciones que, cuando son ejecutadas por el procesador, provocan que la MME:
genere una señal de muestra de autenticación de enlace descendente, DL, con una clave de integridad de Estrato de No Acceso y una identidad de la célula objetivo como entrada, y
envíe un mensaje que incluye la señal de muestra de autenticación de DL generada al eNB (3) objetivo.
13. Un programa informático (14, 15) para restablecer una conexión de Control de Recurso de Radio, RRC, entre un Equipo de Usuario (1), UE, y un NodeB evolucionado (3) objetivo, eNB objetivo, para la optimización de Internet Celular de las Cosas de Plano de Control, comprendiendo el programa informático un código de programa informático que, cuando se ejecuta en el UE (1), provoca que el UE:
reciba (S100) un mensaje de Restablecimiento de Conexión de RRC desde el eNB (3) objetivo, incluyendo el mensaje de Restablecimiento de Conexión de RRC una señal de muestra de autenticación de enlace descendente, DL, que ha sido generada por una Entidad (4) de Gestión de Movilidad y que ha tenido una clave de integridad de Estrato de No Acceso y una identidad de la célula objetivo como entrada, y
autentique (S110) la señal de muestra de autenticación de DL recibida.
14. Un programa informático (34, 35) para restablecer una conexión de Control de Recurso de Radio, RRC, entre un Equipo de Usuario (1), UE, y un NodeB evolucionado (3) objetivo, eNB objetivo, para la optimización de Internet Celular de las Cosas de Plano de Control, comprendiendo el programa informático un código de programa informático que, cuando se ejecuta en el eNB (3) objetivo, provoca que el eNB objetivo:
reciba, desde una Entidad (4) de Gestión de Movilidad, MME, un mensaje que incluye una señal de muestra de autenticación de enlace descendente, DL, que ha sido generada por la MME (4), en donde la señal de muestra de autenticación de DL ha sido generada con una clave de integridad de Estrato de No Acceso y una identidad de la célula objetivo como entrada, y
envíe un mensaje de Restablecimiento de Conexión de RRC al UE (1), incluyendo el mensaje de Restablecimiento de Conexión de RRC la señal de muestra de autenticación de DL.
15. Un programa informático (44, 45) para restablecer una conexión de Control de Recurso de Radio, RRC, entre un Equipo de Usuario (1), UE, y un NodeB evolucionado (3) objetivo, eNB objetivo, para la optimización de Internet Celular de las Cosas de Plano de Control, comprendiendo el programa informático un código de programa informático que, cuando se ejecuta en una Entidad (4) de Gestión de Movilidad, MME, provoca que la MME (4):
genere una señal de muestra de autenticación de enlace descendente, DL, con una clave de integridad de Estrato de No Acceso y una identidad de la célula objetivo como entrada, y
envíe un mensaje que incluye la señal de muestra de autenticación de DL generada al eNB (3) objetivo.
ES20201160T 2017-01-30 2018-01-29 Métodos, aparatos y programas informáticos para restablecer una conexión de Control de Recuso de Radio (RRC) Active ES2936657T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US201762451866P 2017-01-30 2017-01-30

Publications (1)

Publication Number Publication Date
ES2936657T3 true ES2936657T3 (es) 2023-03-21

Family

ID=61163696

Family Applications (3)

Application Number Title Priority Date Filing Date
ES18703269T Active ES2764438T3 (es) 2017-01-30 2018-01-29 Métodos y aparatos para reestablecer una conexión de Control de Recuso de Radio (RRC)
ES20201160T Active ES2936657T3 (es) 2017-01-30 2018-01-29 Métodos, aparatos y programas informáticos para restablecer una conexión de Control de Recuso de Radio (RRC)
ES19196520T Active ES2845874T3 (es) 2017-01-30 2018-01-29 Métodos y aparatos para restablecer una conexión de control de recurso de radio(RRC)

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES18703269T Active ES2764438T3 (es) 2017-01-30 2018-01-29 Métodos y aparatos para reestablecer una conexión de Control de Recuso de Radio (RRC)

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES19196520T Active ES2845874T3 (es) 2017-01-30 2018-01-29 Métodos y aparatos para restablecer una conexión de control de recurso de radio(RRC)

Country Status (11)

Country Link
US (2) US11146951B2 (es)
EP (3) EP3783939B1 (es)
JP (1) JP6725764B2 (es)
KR (1) KR102117644B1 (es)
CN (2) CN112243232A (es)
DK (1) DK3485669T3 (es)
ES (3) ES2764438T3 (es)
HU (1) HUE047851T2 (es)
PL (2) PL3783939T3 (es)
WO (1) WO2018138355A1 (es)
ZA (1) ZA201904139B (es)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109005540B (zh) * 2017-07-28 2019-07-23 华为技术有限公司 一种密钥推演的方法、装置及计算机可读存储介质
CN110830988B (zh) * 2018-08-08 2023-08-15 维沃移动通信有限公司 一种安全更新方法、网络设备及终端
CN110831255B (zh) * 2018-08-09 2023-05-02 大唐移动通信设备有限公司 重建rrc连接的方法、基站、移动终端及存储介质
CN114363890A (zh) * 2018-08-10 2022-04-15 华为技术有限公司 扩展的通用引导架构认证方法、装置及存储介质

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2220883B1 (en) 2007-12-11 2012-05-02 Telefonaktiebolaget L M Ericsson (publ) Methods and apparatuses generating a radio base station key in a cellular radio system
US8145195B2 (en) 2008-04-14 2012-03-27 Nokia Corporation Mobility related control signalling authentication in mobile communications system
WO2010124430A1 (zh) 2009-04-27 2010-11-04 华为技术有限公司 一种无线通信网络的业务恢复方法、装置及系统
KR101700448B1 (ko) * 2009-10-27 2017-01-26 삼성전자주식회사 이동 통신 시스템에서 보안 관리 시스템 및 방법
US20110261961A1 (en) * 2010-04-22 2011-10-27 Qualcomm Incorporated Reduction in bearer setup time
WO2013062388A2 (ko) * 2011-10-27 2013-05-02 삼성전자 주식회사 이동통신 시스템에서 단말의 전력 소모를 효과적으로 감소시키는 방법 및 장치
US9155121B2 (en) 2012-03-27 2015-10-06 Blackberry Limited Re-establishment of suspended RRC connection at a different eNB
US9497673B2 (en) * 2013-11-01 2016-11-15 Blackberry Limited Method and apparatus to enable multiple wireless connections
US10142840B2 (en) * 2015-01-29 2018-11-27 Motorola Mobility Llc Method and apparatus for operating a user client wireless communication device on a wireless wide area network
WO2017189067A1 (en) * 2016-04-29 2017-11-02 Intel IP Corporation Techniques to manage service requests in a wireless network
WO2017189038A1 (en) * 2016-04-29 2017-11-02 Intel IP Corporation CELLULAR IoT CONTROL AND USER PLANE SWITCHING
WO2018031345A1 (en) 2016-08-12 2018-02-15 Intel IP Corporation Initiation of radio resource control (rrc) connection reestablishment using security tokens
US10462837B2 (en) * 2016-11-04 2019-10-29 Qualcomm Incorporated Method, apparatus, and system for reestablishing radio communication links due to radio link failure
WO2018083151A1 (en) 2016-11-07 2018-05-11 Telefonaktiebolaget Lm Ericsson (Publ) Handling radio link failure in a narrow bandwidth internet of things control plane
US10999781B2 (en) * 2016-11-09 2021-05-04 Lg Electronics Inc. Method for transmitting RRC message and wireless device
ES2901650T3 (es) * 2016-12-30 2022-03-23 Huawei Tech Co Ltd Métodos, dispositivo y sistema para el restablecimiento de enlaces
PL3479613T3 (pl) 2017-01-25 2020-06-29 Telefonaktiebolaget Lm Ericsson (Publ) Ponowne nawiązywanie połączenia kontroli zasobów radiowych

Also Published As

Publication number Publication date
EP3783939A1 (en) 2021-02-24
EP3599784B1 (en) 2020-11-18
EP3485669B1 (en) 2019-09-25
KR20190094477A (ko) 2019-08-13
US20220014914A1 (en) 2022-01-13
KR102117644B1 (ko) 2020-06-02
DK3485669T3 (da) 2019-12-16
EP3485669A1 (en) 2019-05-22
EP3783939B1 (en) 2022-11-09
PL3485669T3 (pl) 2020-04-30
HUE047851T2 (hu) 2020-05-28
ES2845874T3 (es) 2021-07-28
ES2764438T3 (es) 2020-06-03
US11146951B2 (en) 2021-10-12
CN112243232A (zh) 2021-01-19
EP3599784A1 (en) 2020-01-29
US20200337104A1 (en) 2020-10-22
WO2018138355A1 (en) 2018-08-02
CN110235459A (zh) 2019-09-13
CN110235459B (zh) 2020-11-03
JP6725764B2 (ja) 2020-07-22
PL3783939T3 (pl) 2023-03-20
US11689922B2 (en) 2023-06-27
JP2020504521A (ja) 2020-02-06
ZA201904139B (en) 2020-12-23

Similar Documents

Publication Publication Date Title
ES2755803T3 (es) Nodos de acceso radioeléctrico y dispositivos terminales en una red de comunicación
ES2936657T3 (es) Métodos, aparatos y programas informáticos para restablecer una conexión de Control de Recuso de Radio (RRC)
ES2935527T3 (es) Manejo del contexto de seguridad en 5G durante el modo conectado
ES2861269T3 (es) Aparatos y procedimientos para comunicación inalámbrica
ES2784977T3 (es) Restablecimiento de una conexión del control de los recursos de radio
US8855603B2 (en) Local security key update at a wireless communication device
US8094817B2 (en) Cryptographic key management in communication networks
BR112018005017B1 (pt) Aparelho e método para procedimento de mobilidade envolvendo relocação de entidade de gerenciamento de mobilidade
ES2548868T3 (es) Métodos y aparatos para generar una clave de estación base de radio y un autentificador de identidad de terminal en un sistema de radio celular
US20110222690A1 (en) Method and system for deriving keys
ES2626666T3 (es) Método y sistema de generación para identificador de identidad de claves durante la transferencia del dispositivo de usuario
BRPI0909124B1 (pt) método e aparelhos para prover separação criptográfica multi-salto para transferências
BR112020002515A2 (pt) método de acionamento de autenticação de rede e dispositivo relacionado
US20220345296A1 (en) Managing Security Keys in a Communication System