ES2971007T3 - Autenticación de equipos de usuario a través de equipos de usuario de retransmisión - Google Patents
Autenticación de equipos de usuario a través de equipos de usuario de retransmisión Download PDFInfo
- Publication number
- ES2971007T3 ES2971007T3 ES18864795T ES18864795T ES2971007T3 ES 2971007 T3 ES2971007 T3 ES 2971007T3 ES 18864795 T ES18864795 T ES 18864795T ES 18864795 T ES18864795 T ES 18864795T ES 2971007 T3 ES2971007 T3 ES 2971007T3
- Authority
- ES
- Spain
- Prior art keywords
- remote
- relay
- network
- application server
- identity
- 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
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/02—Terminal devices
- H04W88/04—Terminal devices adapted for relaying to or from another terminal or user
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B7/00—Radio transmission systems, i.e. using radiation field
- H04B7/14—Relay systems
- H04B7/15—Active relay systems
- H04B7/155—Ground-based stations
- H04B7/15592—Adapting at the relay station communication parameters for supporting cooperative relaying, i.e. transmission of the same data via direct - and relayed path
-
- 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/34—Reselection control
- H04W36/36—Reselection control by user or terminal equipment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
-
- 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/06—Registration at serving network Location Register, VLR or user mobility server
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/03—Protecting confidentiality, e.g. by encryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/60—Context-dependent security
- H04W12/69—Identity-dependent
- H04W12/75—Temporary identity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/11—Allocation or use of connection identifiers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/26—Network addressing or numbering for mobility support
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/10—Small scale networks; Flat hierarchical networks
- H04W84/12—WLAN [Wireless Local Area Networks]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W84/00—Network topologies
- H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
- H04W84/10—Small scale networks; Flat hierarchical networks
- H04W84/14—WLL [Wireless Local Loop]; RLL [Radio Local Loop]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
En algunos ejemplos, un primer equipo de usuario (UE) envía una indicación a un servidor de aplicaciones de que el primer UE debe utilizar un UE de retransmisión para acceder a una red. El primer UE recibe, desde el servidor de aplicaciones, una primera identidad diferente de una segunda identidad del primer UE. El primer UE utiliza la primera identidad para registrarse en la red para autenticar el primer UE. (Traducción automática con Google Translate, sin valor legal)
Description
DESCRIPCIÓN
Autenticación de equipos de usuario a través de equipos de usuario de retransmisión
Campo técnico
La presente invención se refiere a la autenticación de equipos de usuario a través de equipos de usuario de retransmisión.
Antecedentes
Dispositivos como ordenadores, dispositivos portátiles, vehículos, electrodomésticos u otros tipos de dispositivos pueden comunicarse a través de redes cableadas o inalámbricas. Las redes inalámbricas pueden incluir una red de área local inalámbrica (WLAN, por sus siglas en inglés), que incluye puntos de acceso inalámbricos (AP, por sus siglas en inglés) a los que los dispositivos pueden conectarse de forma inalámbrica. Otros tipos de redes inalámbricas incluyen redes celulares que comprenden nodos de red de acceso inalámbrico a los que los dispositivos pueden conectarse de forma inalámbrica.
El documento US 2016/344726 A1 describe un procedimiento para recibir de forma segura un contenido de comunicación crítica asociado con un servicio de comunicación crítica que incluye un servicio push to talk de misión crítica (MCPTT). Se describe una red que proporciona la comunicación crítica que es capaz de establecer una conexión segura al equipo de usuario (UE, por sus siglas en inglés) remoto a través de un UE de retransmisión con el fin de que el UE remoto reciba con seguridad un contenido de comunicación crítica de la red.
El documento deIntel’."System-, application- and IMS-level considerations for MCPTT Network Mode Operation via Relay (NMO-R)" describe una operación básica en modo red soportada con un servidor de MCPTT centralizado, donde el UE remoto se autentica mutuamente con la red y acuerda un material de claves común para su registro en el servicio de MCPTT, y el UE de retransmisión no puede espiar los datos de usuario de los grupos de MCPTT a los que no está afiliado para establecer una sesión de MCPTT.
El documento WO 2017/159451 A1 describe un sistema de comunicación en el que un UE de retransmisión en ProSe permite a un UE remoto conectarse a una estación base y a una red principal a través del UE de retransmisión.
Sumario
La presente invención define un procedimiento realizado por un UE remoto según la reivindicación independiente 1, un UE de retransmisión según la reivindicación independiente 7, y un servidor de aplicaciones según la reivindicación independiente 9. Las realizaciones preferidas se definen en las reivindicaciones dependientes.
Breve descripción de los dibujos
Algunas implementaciones de la presente descripción se describen con respecto a las siguientes figuras.
La Figura 1 es un diagrama de flujo de un procedimiento de un equipo de usuario (UE) remoto según algunos ejemplos.
La Figura 2 es un diagrama de flujo de mensajes de interacciones entre varios nodos según otros ejemplos. La Figura 3 es un diagrama de flujo de mensajes de interacciones entre varios nodos según una primera implementación de la presente descripción.
La Figura 4 es un diagrama de flujo de mensajes de interacciones entre varios nodos según una segunda implementación de la presente descripción.
La Figura 5 es un diagrama de flujo de mensajes de interacciones entre varios nodos en los que se utiliza OAuth según la primera implementación de la presente descripción.
La Figura 6 es un diagrama de flujo de mensajes de interacciones entre un UE de retransmisión y un nodo de red según la primera implementación de la presente descripción.
La Figura 7 es un diagrama de flujo de mensajes de interacciones entre varios nodos según una primera opción de la segunda implementación de la presente descripción.
La Figura 8 es un diagrama de bloques de pilas de protocolos en varios nodos según algunos ejemplos. La Figura 9 es un diagrama de flujo de mensajes de interacciones entre varios nodos según una segunda opción de la segunda implementación de la presente descripción.
La Figura 10 es un diagrama de bloques de pilas de protocolos en varios nodos según otros ejemplos.
La Figura 11 es un diagrama de flujo de mensajes de interacciones entre varios nodos según una tercera opción de la segunda implementación de la presente descripción.
La Figura 12 es un diagrama de bloques de un nodo de red según algunos ejemplos.
A lo largo de los dibujos, los números de referencia idénticos designan elementos similares, pero no necesariamente idénticos. Las figuras no están necesariamente a escala, y el tamaño de algunas partes puede ser exagerado para ilustrar más claramente el ejemplo mostrado. Por otra parte, los dibujos proporcionan ejemplos y/o implementaciones acordes con la descripción; sin embargo, la descripción no se limita a los ejemplos y/o implementaciones proporcionados en los dibujos.
Descripción Detallada
En la presente descripción, el uso del término "un", "una" y "el", "la" pretende incluir también las formas plurales, a menos que el contexto indique claramente lo contrario. Asimismo, el término "incluye", "que incluye", "comprende", "que comprende", "tiene" o "que tiene", cuando se utiliza en esta descripción, especifica la presencia de los elementos indicados, pero no excluye la presencia o adición de otros elementos.
En algunos ejemplos, las redes inalámbricas son redes celulares que funcionan según protocolos celulares. Los protocolos celulares incluyen aquellos proporcionado por el Proyecto de Asociación de Tercera Generación (3GPP, por sus siglas en inglés), tal como las normas de Evolución a Largo Plazo (LTE, por sus siglas en inglés). Las normas de LTE también se conocen como normas de Acceso de Radio Terrestre Universal Evolucionado (E-UTRA, por sus siglas en inglés). Los protocolos celulares también pueden incluir protocolos de próxima generación, incluidos los protocolos de quinta generación (5G) y posteriores. También pueden utilizarse otros protocolos celulares en otros ejemplos.
Otros ejemplos de redes inalámbricas incluyen redes de área local inalámbrica (WLAN). Las WLAN pueden incluir redes inalámbricas, pero sin limitarse a las que funcionan según las especificaciones 802.11, del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) o de la Wi-Fi Alliance, etc.
Aunque se proporcionan ejemplos de algunas redes inalámbricas, las técnicas o mecanismos según algunas implementaciones de la presente descripción pueden utilizarse con cualquiera de los diversos tipos de redes inalámbricas.
Entre los ejemplos de dispositivos inalámbricos capaces de comunicarse en redes inalámbricas se incluyen ordenadores (por ejemplo, tabletas, ordenadores portátiles, ordenadores de sobremesa, etc.), dispositivos portátiles (por ejemplo, teléfonos inteligentes, asistentes digitales personales, dispositivos montados en la cabeza, etc.), dispositivos portátiles (relojes inteligentes, gafas electrónicas, dispositivos montados en la cabeza, etc.), aparatos de juego, monitores de salud, vehículos (o equipos en vehículos), unidades de transporte de cargas (por ejemplo, remolques, contenedores, etc.), dispositivos de Internet de las Cosas (IoT, por sus siglas en inglés) u otros tipos de dispositivos de punto final o de usuario capaces de comunicarse de forma inalámbrica. Los dispositivos inalámbricos pueden incluir dispositivos móviles y/o dispositivos de posición fija. En términos más generales, un dispositivo inalámbrico puede referirse a un dispositivo electrónico capaz de comunicarse de forma inalámbrica.
En el análisis subsiguiente, los dispositivos inalámbricos se denominan "equipos de usuario (UEs)" Un UE puede referirse a un UE con una UICC, o a un Equipo móvil (ME, por sus siglas en inglés) sin una UICC, o a cualquier otro tipo de dispositivo inalámbrico.
Como se utiliza en este caso, un "UE remoto" puede referirse a un dispositivo inalámbrico que puede no tener acceso a una red inalámbrica, tal como una red celular. Un UE remoto puede utilizar un UE de retransmisión para acceder a una red inalámbrica, tal como una red celular. Un "UE de retransmisión" es un dispositivo inalámbrico que permite a otro tipo de dispositivo inalámbrico, tal como un UE remoto, utilizar un UE de retransmisión para acceder a una red inalámbrica. Un ejemplo de un UE de retransmisión es un UE de retransmisión de Capa 2. Un UE remoto es un UE de un primer tipo, mientras que un UE de retransmisión es un UE de un segundo tipo diferente del primer tipo.
En algunos ejemplos, el UE remoto se comunica con el UE de retransmisión utilizando un primer tipo de tecnología inalámbrica, que incluye cualquiera o alguna combinación de lo siguiente: Bluetooth, WLAN, dispositivo a dispositivo (D2D, por su siglas en inglés) (tal como PC5, ProSe D2D, Sidelink, Comunicación Directa de Corto Alcance (DirectShort Range Communication (DSRC, por sus siglas en inglés)), IEEE 802.11 p, etc.), Comunicación de Campo Cercano (Near Field Communication (NFC, por sus siglas en inglés)), IoT de banda ancha (NarrowBand IoT(NB-IoT, por sus siglas en inglés)), etc. El UE de retransmisión puede comunicarse con una red inalámbrica que utilice un segundo tipo de tecnología inalámbrica, tal como la red de Acceso Universal Radioeléctrico Terrestre (UTRAN, por sus siglas en inglés), la red de Acceso Radioeléctrico GSM/EDGE (GERAN, por sus siglas en inglés), las velocidades de datos mejoradas para la evolución GSM (EDGE, por sus siglas en inglés), WLAN, LTE, 5G, etc.
En ejemplos más específicos, un UE de retransmisión de Capa 2 permite a un UE remoto acceder a la conectividad y a los servicios proporcionados por una red de 3GPP a través del UE de retransmisión. En algunos ejemplos, la señalización de Estrato de Acceso de Red (NetworkAccess Stratum (NAS, por sus siglas en inglés)) comunicada por el UE remoto puede pasar claramente a través de una función de retransmisión en el UE de retransmisión con la red de 3GPP. La función de retransmisión puede ser proporcionada como parte de la Capa 2 del UE de retransmisión.
En ejemplos en los que la red inalámbrica es una UTRAN evolucionada (e-UTRAN, por sus siglas en inglés), el UE remoto puede entonces referirse a un UE remoto evolucionado, y el UE de retransmisión puede referirse a un UE de retransmisión evolucionado.
En el contexto de los servicios de seguridad pública, tales como los definidos por 3GPP como "Push to talk de misión crítica" (MCPTT), un UE de retransmisión puede referirse a una entidad que puede desplegarse para ampliar la cobertura de 3GPP de un dispositivo que puede no tener cobertura de 3GPP, como en el caso de un accidente automovilístico o un incidente de emergencia en el que un grupo de primera intervención (tal como la policía) puede instalar uno o más UE de retransmisión para proporcionar una mejor cobertura a otros primeros intervinientes que acudan al incidente.
Una cuestión que se plantea en el contexto en el que un UE remoto debe acceder a una red inalámbrica utilizando un UE de retransmisión, tal como un UE de retransmisión de Capa 2, es la realización de la autenticación de red del UE remoto cuando el UE remoto no desea divulgar su identidad privada. Una identidad privada también puede denominarse Identidad Privada de Usuario (ID, por sus siglas en inglés). Generalmente, una propiedad de una identidad privada es que la identidad privada sólo es conocida por la red inalámbrica y por el UE remoto.
Un ejemplo de ID privada de usuario asociada a un UE remoto puede incluir un identificador uniforme de recursos (URI, por sus siglas en inglés) del Protocolo de Iniciación de Sesión (SIP, por sus siglas en inglés) o una IMSI. Como ejemplo adicional, una ID privada de usuario también puede ser una ID temporal. Una ID temporal puede incluir cualquiera de los siguientes: una ID Temporal Única Global (GUTI, por sus siglas en inglés), una Identidad Temporal de Abonado Móvil (TMSI, por sus siglas en inglés), una Identidad Temporal de Abonado Móvil por Paquetes (P-TMSI, por sus siglas en inglés), una 5G-GUTI, etc. Las características de una ID temporal es que la identidad tiene una vida útil finita y puede ser asignada a otro UE en un momento diferente o en una ubicación diferente.
En general, el término "identidad" se refiere tanto a una identidad privada como a una identidad pública.
La Figura 1 es un diagrama de flujo de un procedimiento 100 que puede realizar un UE remoto para llevar a cabo la autenticación. El UE remoto envía (en 102) una indicación a un servidor de aplicaciones (AS) de que el UE remoto va a utilizar un UE de retransmisión para acceder a una red. Un servidor de aplicaciones (también denominado "servidor de acceso") es una entidad que puede realizar cualquiera o una combinación de lo siguiente: interfuncionamiento de protocolos entre un primer protocolo y un segundo protocolo; una función de autenticación o una función de autenticación proxy; una función de agente de usuario back-to-back (B2BUA, por sus siglas en inglés), que es un elemento lógico de red SIP; una función de asignación de identidad de usuario, una función de gestión de acceso y movilidad (AMF, por sus siglas en inglés), etc.
Un B2BUA es una entidad lógica que recibe una petición y la procesa como un servidor de agente de usuario (UAS, por sus siglas en inglés). Para determinar cómo debe responderse a la petición, el B2BUA actúa como un agente de usuario cliente (UAC, por sus siglas en inglés) y genera peticiones. A diferencia de un servidor proxy, el B2BUA mantiene un estado de diálogo y participa en todas las solicitudes enviadas en los diálogos que el B2BUA ha establecido.
En algunos ejemplos, se supone que el UE remoto no tiene conectividad celular. Sin embargo, cabe señalar que las técnicas o mecanismos según algunas implementaciones también son aplicables en ejemplos en los que el UE tiene conectividad celular.
En el procedimiento 100, el UE remoto recibe (en 104), del servidor de aplicaciones, una primera identidad diferente de una segunda identidad del UE remoto. Por ejemplo, la segunda identidad puede ser una identidad privada del UE remoto mencionada anteriormente. Por otra parte, la primera identidad puede ser una ID temporal, por ejemplo.
El UE remoto utiliza (en 106) la primera identidad para registrarse en la red, donde el registro da lugar a la autenticación del UE remoto.
De este modo, el UE remoto no tiene que divulgar su identidad privada al realizar la autenticación.
La Figura 2 es un diagrama de flujo de mensajes de un procedimiento de autenticación según otros ejemplos en el que intervienen un UE remoto, un UE de retransmisión, un servidor de aplicaciones denominado AS1 y varios nodos de red, incluidos MMEa, MMEb, P-GW y Nodo de Red 1. MME representa una entidad de gestión de la movilidad (Mobility Management Entity), que es un nodo de la red principal de LTE que realiza diversas tareas de control del acceso de un UE a una red de acceso de LTE. En otros ejemplos, se puede utilizar un tipo diferente de nodo de gestión de la movilidad en lugar de una MME de LTE, tal como una función de gestión del acceso y movilidad (AMF) de una red 5G.
En la Figura 2, MMEa y MMEb representan dos MME diferentes. Aunque en la Figura 2 se muestran dos MME, como se observa en otros ejemplos, sólo se puede emplear una MME.
P-GW representa una Pasarela a la Red de Datos por Paquetes (Packet Data Network Gateway), que es un nodo de red principal de LTE y es una pasarela que está conectada a una PDN (por ejemplo, Internet u otro tipo de red de datos) para comunicar paquetes de datos de tráfico entre los UE y la PDN. En otros ejemplos, en lugar de una P-GW, se puede utilizar un tipo diferente de nodo de red principal para las comunicaciones de datos de tráfico, tal como una función de plano de usuario (UPF, por sus siglas en inglés) de una red 5G.
En un ejemplo diferente, el AS1 puede ser sustituido por una función de interfuncionamiento no 3GPP (N3IWF, por sus siglas en inglés) de una red 5G. Como alternativa, el AS1 puede ser sustituido por una Pasarela de Paquetes de Datos Evolucionada (ePDG, por sus siglas en inglés). De este modo, la expresión "servidor de aplicaciones" puede referirse a un servidor de aplicaciones, una N3IWF, una ePDG o cualquier otra entidad designada para realizar tareas específicas.
El Nodo de Red 1 mostrado en la Figura 1 está destinado a realizar servicios de autenticación. En algunos ejemplos, el Nodo de Red 1 puede incluir un servidor de Autenticación, Autorización y Contabilidad (AAA, por sus siglas en inglés), una Función de Servidor de Autenticación (AUSF), o cualquier otro tipo de nodo que pueda proporcionar servicios de autenticación.
La Figura 2 muestra varias tareas que pueden realizarse entre las entidades mostradas en la Figura 2.
Tarea 1: El UE remoto se registra y/o asocia con el UE de retransmisión. El registro y/o asociación del UE remoto con el UE de retransmisión permite al UE remoto intercambiar información con el UE de retransmisión, de modo que el UE remoto puede obtener información del UE de retransmisión, tal como información de configuración del UE de retransmisión. Una vez que el UE remoto y el UE de retransmisión están asociados, el UE remoto puede utilizar el UE de retransmisión para comunicarse con una red inalámbrica.
Tarea 2: En respuesta a la asociación entre el UE remoto y el UE de retransmisión, el UE de retransmisión crea una conexión de datos con la P-GW si aún no existe y proporciona conectividad a AS1. La característica clave de la conexión de datos es que proporciona acceso a AS1. Otra característica podría ser que la conexión de datos sólo proporciona conectividad a AS1.
Tarea 3: A continuación, el UE remoto establece una conexión segura con el servidor de aplicaciones AS1 en la red. Una conexión segura permite al UE remoto comunicarse con AS1, sin que otra entidad (tal como el UE de retransmisión) pueda ver la información que se intercambia entre el UE remoto y AS1. El UE de retransmisión incluye una función que, al recibir una solicitud de una dirección de protocolo de Internet (IP, por sus siglas en inglés) asociada al servidor de aplicaciones AS1, restringe el acceso del UE remoto. La restricción de acceso permite al UE remoto acceder sólo a los servicios especificados del AS1, hasta después de que el UE remoto se haya autenticado.
Tarea 4: En todas las realizaciones de la presente invención, el UE remoto solicita una ID temporal para AS1, enviando la identidad privada del UE remoto a AS1. La ID temporal (o más generalmente una segunda identidad del UE remoto que es diferente de una identidad privada del UE remoto) es utilizada por el UE remoto con fines de autenticación.
Tarea 5: La ID temporal u otra segunda identidad puede ser obtenida por AS1 de diferentes maneras. En algunos ejemplos, la segunda identidad es asignada por AS1. En otros ejemplos, la segunda identidad es asignada por un nodo de gestión de la movilidad, tal como la MMEb de la Figura 2 u otro tipo de nodo de gestión de la movilidad.
En los ejemplos en los que la segunda identidad es asignada por AS1, pueden implementarse dos opciones (Opción A y Opción C). En ejemplos alternativos en los que la segunda identidad es asignada por un nodo de gestión de la movilidad, se implementa la opción B.
Tarea 5: Con la Opción A, la segunda identidad (asignada por AS1) y la identidad privada del UE remoto se envían en un mensaje a un Servidor de Abonado Domiciliario (HSS, por sus siglas en inglés), que es un ejemplo del Nodo de Red 1 en la Figura 2. El HSS responde al mensaje creando un enlace de la identidad privada del UE remoto con la segunda identidad asignada por el AS1.
Tarea 6: Con la Opción B, AS1 obtiene, de MMEb o de otro nodo de gestión de la movilidad, la ID temporal u otra segunda identidad. La segunda identidad puede ser una GUTI, por ejemplo. AS1 obtiene la segunda identidad enviando la identidad privada del UE remoto a MMEb o a otro nodo de gestión de la movilidad.
Tarea 7: AS1 envía la ID temporal, que forma parte de todas las realizaciones de la presente invención, u otra segunda identidad al UE remoto. El UE remoto vincula la ID temporal u otra segunda identidad proporcionada por AS1 a la identidad privada del UE remoto.
Tareas 8, 9: En respuesta a la recepción de la ID temporal u otra segunda identidad, el UE remoto se registra en la red inalámbrica utilizando la identidad temporal, que forma parte de todas las realizaciones de la presente invención, u otra segunda identidad. El UE remoto envía un mensaje de registro que contiene la ID temporal u otra segunda identidad al UE de retransmisión (Tarea 8) que, a su vez, reenvía (Tarea 9) el mensaje de registro a MMEa (u otro nodo de gestión de la movilidad).
Tarea 10: Con la Opción A o B, MMEa u otro nodo de gestión de la movilidad envía una solicitud (que contiene la ID temporal u otro segundo identificador) para obtener vectores de autenticación del Nodo de Red 1 (por ejemplo, el HSS). Los vectores de autenticación contienen información de autenticación utilizada para realizar la autenticación del UE remoto. El HSS asigna la segunda identidad recibida a la identidad privada del UE remoto, o bien el HSS no realiza esta asignación.
Tareas 11, 12: Con la Opción C como ejemplo ilustrativo para una mejor comprensión de la presente invención que no está abarcada por las reivindicaciones adjuntas, la ID temporal u otra segunda identidad tiene un formato (por ejemplo, una IMSI, E.212, etc.) de modo que la entidad (por ejemplo, MMEa u otro nodo de gestión de la movilidad) que recibe la solicitud de registro del UE remoto (Tarea 9) envía una solicitud a AS1 (Tarea 11). A continuación, AS1 sustituye la ID temporal u otra segunda identidad por la identidad privada del UE remoto recibida por AS1 en la Tarea 4. Después de que AS1 haya sustituido la ID temporal u otra segunda identidad por la identidad privada del UE remoto, AS1 envía una solicitud para obtener vectores de autenticación al Nodo de Red 1 (Tarea 12).
Tarea 13: En ejemplos en los que MMEa y MMEb no son la misma entidad, MMEa envía una solicitud de identificación a MMEb para obtener de MMEb información de identidad y contexto.
Tarea 14: En respuesta a la solicitud de identificación, MMEb envía a MMEa información de identidad y contexto. En otros ejemplos, MMEa y MMEb pueden referirse a otros tipos de nodos de gestión de la movilidad.
En el análisis subsiguiente, se asume que sólo hay un nodo de gestión de la movilidad. Sin embargo, en general, las técnicas o mecanismos que se comentan más adelante pueden aplicarse en ejemplos en los que hay varios nodos de gestión de la movilidad (por ejemplo, MMEa y MMEb en la Figura 2).
A continuación se describen otros detalles relativos a varias implementaciones diferentes (por ejemplo, Implementación 1, Implementación 2, etc.) según algunas realizaciones de la presente descripción. Se hace referencia a diferentes secciones, tales como la sección 1.1, así como a subsecciones de estas secciones.
Sección 1.1, Implementación 1
1.1.0, Generalidades
En la Implementación 1, el UE remoto construye un túnel a través del UE de retransmisión hacia AS1 en la red. AS1 asigna una segunda identidad (por ejemplo, una ID temporal u otro token) al UE remoto para que el UE remoto utilice posteriormente la segunda identidad cuando el UE remoto realice un registro a través del UE de retransmisión utilizando un mecanismo de conectividad de Capa 2, por ejemplo.
La tunelización se consigue por medio del UE de retransmisión que tiene una conexión de PDP (Packet Data Protocol, Protocolo de Datos por Paquete) configurada que sólo permite el acceso restringido por parte del UE remoto a un servidor de aplicaciones (por ejemplo, AS1) hasta que se autentica el UE remoto. Obsérvese que el UE de retransmisión permite el acceso restringido por parte del UE remoto a una entidad funcional (AS1) que puede estar ubicada en una red totalmente distinta (de la red a la que está conectado el UE de retransmisión). En otras palabras, el UE de retransmisión no sólo restringe el acceso a un servidor de aplicaciones de una red local del UE de retransmisión.
Lo que sigue se refiere a la Figura 3. En la Figura 3, donde hay dos o más entidades representadas en una pila vertical, eso implica que cualquiera de las entidades de la pila vertical puede realizar la(s) función(es) respectiva(s) representada(s) en la Figura 3.
Por ejemplo, en la Figura 3, una MME o una AMF pueden realizar las tareas de un nodo de gestión de la movilidad. Asimismo, tanto una P-GW como una UPF (o alternativamente, una entidad que incluya tanto P-GW como UPF) pueden realizar tareas de pasarela de datos. Del mismo modo, cualquiera de AS1, ePDG, o N3IWF (o alternativamente, cualquier combinación de AS1, ePDG, N3IWF) puede realizar tareas de un servidor de aplicaciones.
La Figura 3 muestra además otro servidor de aplicaciones que puede implementarse con AS2 o AMF2 (o alternativamente, una combinación de AS2 y AMF2). Como otra alternativa, el otro servidor de aplicaciones puede ser implementado como cualquiera o alguna combinación de AS1 y N3IWF. Asimismo, en la Figura 3, las tareas del Nodo de Red 1 pueden implementarse con un servidor AAA o una AUSF (o, alternativamente, una combinación de ambos).
En la Figura 3, las Tareas 3, 3b y 6 pueden implementarse utilizando el Protocolo de Autenticación Extensible (EAP, por sus siglas en inglés) o el protocolo OAuth 2.0 para realizar la autenticación.
Observe también que en la Figura 3 no hay relación temporal entre las Tareas 7 y 8 - estas tareas pueden producirse en cualquier orden y de forma asíncrona.
1.1.1, Operación de UE remoto
A continuación se hace referencia a varias tareas de la Figura 3 que son realizadas por el UE remoto con la Implementación 1.
Tarea 1: El UE remoto se asocia/registra con el UE de retransmisión y recupera información relativa al UE de retransmisión, donde la asociación permite que el UE remoto envíe paquetes de datos, por ejemplo, paquetes de IP, al UE de retransmisión. La información recuperada por el UE remoto del UE de retransmisión puede incluir cualquiera, alguno o ninguno de lo siguiente: una identidad del UE de retransmisión, la red (por ejemplo, una red móvil terrestre pública registrada o RPLMN, por sus siglas en inglés) a la que está conectado el UE de retransmisión, la ubicación del UE de retransmisión, la dirección de AS1, etc. Tal y como se utiliza en este caso, una "ubicación" puede referirse a cualquier o alguna combinación de un código de país móvil (MCC, por sus siglas en inglés), un código de red móvil (MNC, por sus siglas en inglés), una identidad celular, coordenadas GPS, detalles de puntos de referencia, un identificador de conjunto de servicios (SSID, por sus siglas en inglés), un código de operador, un área de localización (LA, por sus siglas en inglés), un área de enrutamiento (RA, por sus siglas en inglés), un área de seguimiento (TA, por sus siglas en inglés), etc.
Tarea no mostrada: El UE remoto establece una conexión segura con un AS1 utilizando información obtenida del UE de retransmisión o información de configuración interna del UE remoto.
Tarea 3: El UE remoto envía una indicación (mediante EAP u OAuth, por ejemplo) a AS1 de que el UE remoto desea utilizar un UE de retransmisión como recurso para acceder a la red principal. El UE remoto puede enviar en la indicación o en asociación con la indicación una o más de las siguientes informaciones: una identidad del UE de retransmisión, la red a la que está conectado el UE de retransmisión, la ubicación del UE (UE remoto y/o UE de retransmisión), una indicación de que el UE remoto desea utilizar un UE de retransmisión, etc.
Tarea 6: El UE remoto recibe un token de AS1, donde el token es o contiene la segunda identidad a utilizar al registrarse para el acceso de capa 2 con el UE de retransmisión.
Tarea 8: El UE remoto envía un mensaje de NAS (por ejemplo, Conexión, Actualización de ubicación, Actualización de área de enrutamiento, Actualización de área de seguimiento, etc.) al UE de retransmisión que contiene la segunda identidad del token. El mensaje de NAS es un ejemplo de solicitud de registro utilizada por el UE remoto para registrarse en la red, de modo que el UE remoto puede autenticarse y obtener servicios de red de la red.
Tarea 13: El UE remoto recibe un desafío de autenticación según normas existentes (normas que se promulgan actualmente). Este desafío de autenticación es iniciado (Tarea 12) por un nodo de gestión de la movilidad (por ejemplo, MME o AMF) en respuesta a los vectores de autenticación enviados (Tarea 11) por el Nodo de Red 1 (o alternativamente, el servidor AAA o AUSF) en respuesta a la solicitud de registro por parte del UE remoto. El UE de retransmisión reenvía el desafío de autenticación al UE remoto (tarea 12).
Tarea 14: El UE remoto responde al desafío de autenticación según las normas existentes
1.1.2, Operación de UE de retransmisión
A continuación se hace referencia a varias tareas de la Figura 3 que son realizadas por el UE de retransmisión con la Implementación 1.
Tarea 1: El UE de retransmisión se asocia con el UE remoto y puede proporcionar alguna, parte o ninguna de las siguientes informaciones al UE remoto: una identidad del UE de retransmisión, red a la que está conectado el UE de retransmisión, la ubicación del UE de retransmisión, una dirección de AS1, etc.
Tarea 2: El UE de retransmisión crea un contexto de PDP para crear una conexión de datos con la red. El contexto de PDP tiene la característica de que el contexto de PDP sólo proporciona conectividad por parte del UE remoto a la dirección de un servidor de aplicaciones (por ejemplo, AS1). Esta tarea es opcional si el contexto de PDP ya existe.
Tarea 3: El UE de retransmisión recibe un paquete de datos (por ejemplo, un paquete de IP) del UE remoto que contiene una dirección de destino (por ejemplo, una dirección IP). El paquete de IP puede incluir la indicación enviada por el UE remoto a AS1 de que el UE remoto desea utilizar un UE de retransmisión como recurso para acceder a la red principal.
Tarea 3b: El UE de retransmisión o bien:
• comprueba si la dirección IP de destino recibida en el paquete de IP está "permitida" (por ejemplo, la dirección IP es la dirección de AS1); el UE de retransmisión reenvía el paquete de IP a AS1 si la dirección IP de destino está "permitida"; o bien
• envía el paquete de IP a una dirección IP preconfigurada en el UE de retransmisión, donde la dirección IP preconfigurada es la del AS1.
En algunos ejemplos, la dirección de AS1 y un nombre de punto de acceso (APN, por sus siglas en inglés) utilizados para crear el contexto de PDP pueden ser obtenidos por el UE de retransmisión de una de las siguientes maneras:
1. el UE de retransmisión recibe la dirección de AS1 y el APN de la red en un elemento de información de Opciones de Configuración de Protocolo (PCO, por sus siglas en inglés) en un mensaje de NAS cuando el UE de retransmisión se comunica (por ejemplo, se conecta) con la red; o bien
2. la dirección de AS1 y el APN están almacenados en una tarjeta de circuito integrado universal (UICC, por sus siglas en inglés) del UE de retransmisión (en este caso, el UE de retransmisión leerá la dirección de AS1 y el APN en la memoria); o bien
3. la dirección de AS1 y el APN se proporcionan en el equipo móvil (ME), que es un UE sin UICC
El elemento de información de PCO se define en TS 24.008 de 3GPP, y permite a un UE, a través de indicadores (donde un indicador puede incluir uno o más bits o incluso la ausencia de uno o más bits en un mensaje) enviados a la red, indicar a la red la información que el UE está solicitando. La red puede responder al UE con esa información. Tarea 8: El UE de retransmisión recibe el mensaje de NAS (por ejemplo, Conexión) enviado por el UE remoto. Tarea 9: El UE de retransmisión envía el mensaje de NAS (por ejemplo, Conexión) u otra solicitud de registro a la red. Tarea 12: El UE de retransmisión recibe el desafío de autenticación iniciado por un nodo de gestión de la movilidad (por ejemplo, MME o AMF) en respuesta a los vectores de autenticación enviados (Tarea 11) por el Nodo de Red 1 (o alternativamente, el servidor AAA o AUSF) en respuesta a la solicitud de registro por parte del UE remoto.
Tarea 13: El UE de retransmisión envía el desafío de autenticación al UE remoto.
Tarea 14: El UE de retransmisión recibe una respuesta al desafío de autenticación según las normas existentes. Tarea 15: El UE de retransmisión envía la respuesta al desafío de autenticación a la red según las normas existentes.
1.1.3, Operación de AS1
A continuación se hace referencia a varias tareas de la Figura 3 que son realizadas por AS1 con la Implementación 1. Tarea no mostrada: AS1 establece una conexión segura con el UE remoto.
Tarea 3: AS1 recibe del UE remoto una indicación de que el UE remoto desea utilizar un UE de retransmisión como recurso. La información enviada en o con la indicación por el UE remoto a AS1 puede incluir cualquiera o alguna combinación de las siguientes: una identidad del UE de retransmisión, la red a la que está conectado el UE de retransmisión, la ubicación del UE (UE remoto y/o UE de retransmisión), etc.
Tarea 4: Si AS1 no puede completar la configuración de la conexión segura, por ejemplo, porque AS1 se encuentra en una red visitada, entonces AS1 envía la información recibida en la Tarea 3 a AS2.
Tarea 5: Si el UE remoto está autorizado a utilizar el UE de retransmisión, entonces AS2 crea una indicación que es o contiene la segunda identidad para el UE remoto, donde la indicación puede incluir el token señalado anteriormente, por ejemplo.
Tarea 6: AS1 envía un token al UE de retransmisión, donde el token es o contiene la segunda identidad.
Tarea 7: AS1 o AS2 envía un mensaje al Nodo de Red 1 que contiene al menos uno de lo siguiente: el token, la identidad del UE remoto, la identidad del UE de retransmisión, etc.
1.1.4, Operación de Nodo de Red 1
A continuación se hace referencia a varias tareas de la Figura 3 que son realizadas por el Nodo de Red 1 con la Implementación 1. El Nodo de Red 1 puede ser cualquiera de lo siguiente: HSS, Registro de Ubicación Local (HLR, por sus siglas en inglés}Centro de autenticación (AuC, por sus siglas en inglés), 5G AUSF, servidor AAA, etc.
Tarea 7: El Nodo de Red 1 recibe un mensaje de AS1 que contiene al menos uno de: el token, la identidad del UE remoto, la identidad del UE de retransmisión, etc. En respuesta, el Nodo de Red 1 crea un enlace o asignación entre al menos 2 de: la identidad del UE remoto, la identidad del UE de retransmisión, y la segunda identidad en el token. Tarea 10: El Nodo de Red 1 recibe del nodo de gestión de la movilidad (por ejemplo, MME o AMF) un mensaje solicitando vectores de autenticación para la segunda identidad. El mensaje contiene opcionalmente la identidad del UE de retransmisión. El mensaje recibido en la Tarea 10 se produce en respuesta a la solicitud de registro reenviada por el UE de retransmisión desde el UE remoto al nodo de gestión de la movilidad. El Nodo de Red 1 determina la identidad privada del UE remoto utilizando la segunda identidad para poder recuperar los vectores de autenticación. Opcionalmente, el Nodo de Red 1 comprueba la identidad del UE de retransmisión comparándola con la identidad del UE de retransmisión creada en el enlace o asignación que forma parte de la Tarea 7 anterior.
Tarea 11: El Nodo de Red 1 envía vectores de autenticación al nodo de gestión de la movilidad.
Sección 1.2, Implementación 2
1.2.0, Generalidades
La aplicación 2 se representa en la Figura 4.
La Implementación 2 es similar a la Implementación 1, salvo que un nodo de gestión de la movilidad (por ejemplo, MME o AMF) asigna la segunda identidad al UE remoto, y envía la segunda identidad asignada de vuelta a AS1 para que AS1 envíe la segunda identidad al UE remoto para su uso en la Tarea 8 de la Figura 4.
Como parte del procedimiento de asignación, la MME autentica al UE remoto mediante procedimientos estándar (procedimientos regidos por las normas vigentes). Las diferencias propuestas entre las Implementaciones 1 y 2 se muestran en el perfil discontinuo de la Figura 4.
En la sección 2.2 se describen tres implementaciones diferentes de las Tareas 3-6 (que incluyen opcionalmente las Tareas 4a, 4b y 5a-5e) en la Figura 4.
Una primera de las tres implementaciones diferentes consiste en enviar mensajes de NAS directamente desde el UE remoto a través de AS1 al nodo de gestión de la movilidad.
Una segunda de las tres implementaciones diferentes consiste en enviar mensajes de Intercambio de Claves de Internet (IKE, por sus siglas en inglés>€AP desde el UE remoto a AS1, donde el AS1 entonces interconecta los mensajes de IKE/EAP a NAS enviados al nodo de gestión de la movilidad.
Una tercera de las tres implementaciones diferentes consiste en enviar mensajes de IKE/EAP desde el UE remoto a AS1, donde el AS1 asigna una ID de Usuario Privado (por ejemplo, IMSI) al UE remoto, la IMSI tiene las características de que el enrutamiento en la red es resultado de mensajes de Diámetro o Parte de Aplicación de Movilidad (MAP, por sus siglas en inglés) que solicitan vectores de autenticación para ser enviados al AS1.
1.2.1, Operación de UE remoto
La operación del UE remoto en la Implementación 2 es similar a la de la Implementación 1, excepto con las siguientes adiciones.
Tarea 5c: El UE remoto recibe un desafío de autenticación de AS1 que forma parte del procedimiento de obtención de la segunda identidad de AS1.
Tarea 5d: El UE remoto envía una respuesta de vuelta al desafío de autenticación a AS1.
1.2.2, Operación de UE de retransmisión
La operación del UE de retransmisión en la Implementación 2 es similar a la del UE de retransmisión en la Implementación 1.
1.2.3, Operación de AS1
La operación de AS1 en la Implementación 2 es similar a la de AS1 en la Implementación 1, excepto con las siguientes adiciones y/o modificaciones.
Tarea 3: AS1 recibe del UE remoto mediante un primer protocolo una indicación de que el UE remoto desea utilizar un UE de retransmisión como recurso para acceder a la red. En algunos ejemplos, el primer protocolo puede incluir EAP o NAS sobre IP, o alternativamente, un protocolo diferente. La información recibida por AS1 del UE remoto como parte de la indicación o asociada a ella incluye uno o alguno de: la identidad del UE de retransmisión, la red a la que está conectado el UE de retransmisión, la ubicación del UE (UE remoto y/o UE de retransmisión), etc.
Tarea 4a: En respuesta a la indicación y a la información asociada (enviada por el UE remoto en la Tarea 3 y reenviada por el UE de retransmisión en la Tarea 3b), AS1 envía una solicitud al nodo de gestión de la movilidad para la segunda identidad utilizando un segundo protocolo. La solicitud contiene la identidad del UE remoto recibida en la Tarea 3. El segundo protocolo puede ser diferente del primer protocolo y puede ser el protocolo NAS o un protocolo diferente.
Tarea 5b: AS1 recibe un desafío de autenticación del nodo de gestión de la movilidad utilizando el segundo protocolo.
Tarea 5c: AS1 envía el desafío de autenticación al UE remoto utilizando el primer protocolo.
Tarea 5d: AS1 recibe la respuesta del desafío de autenticación del UE remoto utilizando el primer protocolo
Tarea 5e: AS1 envía la respuesta del desafío de autenticación al nodo de gestión de la movilidad utilizando el segundo protocolo.
Tarea 4b: AS1 recibe, del nodo de gestión de la movilidad, una respuesta que contiene la segunda identidad utilizando el segundo protocolo.
Tarea 6: AS1 envía un token (que contiene la segunda identidad para el UE remoto) al UE remoto utilizando el primer protocolo.
1.2.4, Operación de Nodo de Red 1
La operación del Nodo de Red 1 en la Implementación 2 es similar a la del Nodo de Red 1 en la Implementación 1, excepto con la siguiente adición.
Tarea 5a: El Nodo de Red 1 recibe, del nodo de gestión de la movilidad, una solicitud de vectores de autenticación. La solicitud de vectores de autenticación enviada por el nodo de gestión de la movilidad se produce en respuesta a la solicitud de AS1 enviada al nodo de gestión de la movilidad para la segunda identidad.
En respuesta a los vectores de autenticación recibidos del Nodo de Red 1, el nodo de gestión de la movilidad envía un desafío de autenticación a AS1 (Tarea 5b).
Sección 2.1, Detalles de la Implementación 1
A continuación se ofrecen más detalles sobre las distintas tareas de la Implementación 1 comentadas en la Sección 1.1.
2.1.1, Flujo de información general
Lo siguiente se refiere a la Figura 3, que muestra un flujo de mensajes para la Implementación 1.
Tarea 1: El UE remoto establece una conexión con el UE de retransmisión y puede obtener cualquiera de los siguientes elementos o una combinación de ellos:
a. una identidad del UE de retransmisión,
b. una identidad de la red (por ejemplo, código PLMN, Identificador de Conjunto de Servicios (SSID), etc.) a la que está conectado el UE de retransmisión,
c. la ubicación del UE de retransmisión,
d. la dirección de AS1 (véase la Tarea 2 para las posibles formas en que la dirección puede ser obtenida por el UE de retransmisión).
El UE remoto almacena la información anterior recibida del UE de retransmisión.
Si la dirección de AS1 es un Nombre de Dominio Completamente Cualificado (FQDN, por sus siglas en inglés), puede producirse una de las siguientes situaciones.
a) El UE de retransmisión añade información de su ubicación al FQDN y envía el FQDN y la información de ubicación al UE remoto.
b) El UE remoto recibe el FQDN y la información de ubicación del UE de retransmisión. El UE remoto añade la información de ubicación al FQDN.
Tarea 2: Si el UE de retransmisión no tiene ya una conexión de datos con la red, el UE de retransmisión crea una conexión de datos con la red. El identificador (por ejemplo, APN) utilizado para identificar la red de datos a la que conectarse se configura en el ME de retransmisión o en la UICC del UE de retransmisión, o se obtiene de la red. En las implementaciones en las que el identificador de AS se configura en el ME de retransmisión o en la UICC, en la Tabla 1 siguiente se exponen ejemplos de cambios en TS 31.102 de 3GPP o TS 31.103 de 3GPP que pueden realizarse para permitir la configuración del identificador en el ME de retransmisión o en la UICC. El texto subrayado en la Tabla 1 indica ejemplos de cambios realizados en cualquiera de las dos normas, TS 31.102 de 3GPP o TS 31.103 de 3GPP. Aunque en la presente descripción se incluyen cambios de ejemplo propuestos a diversas normas, cabe señalar que las técnicas o mecanismos según algunas implementaciones de la presente descripción pueden implementarse con otros cambios en las normas, o incluso en implementaciones en las que no se utilizan cambios en las normas. Asimismo, cuando la palabra "deberá" aparece en el texto de un cambio propuesto, esa palabra también puede abarcar otros ejemplos en los que "deberá" se sustituye por "debería" o "puede"
TABLA 1
Alternativamente, el UE de retransmisión puede obtener la dirección de AS1 de la red, lo que se describe en la sección 2.1.3 más adelante.
Una característica de la conexión de datos establecida por el UE de retransmisión es que la conexión de datos permite a un UE remoto un acceso restringido para comunicarse únicamente con un servidor de aplicaciones (AS1).
El UE de retransmisión crea una correspondencia entre el equipo remoto y la conexión de datos establecida.
Si la conexión de datos ya existe, el UE de retransmisión crea una correspondencia entre el equipo remoto y la conexión de datos existente.
Tareas 3, 3b: El UE remoto establece una conexión segura con AS1 en la red y puede incluir en el mensaje de configuración segura o en un mensaje posterior (por ejemplo, un mensaje de registro) en el procedimiento de configuración segura cualquiera de los siguientes:
a. cualquiera de las informaciones almacenadas por el UE de retransmisión en la Tarea 1; o
b. la segunda identidad del UE remoto; o
c. otra información.
En respuesta a la recepción de un paquete IP del UE remoto, el UE de retransmisión envía el paquete IP recibido desde el UE de retransmisión a través de la conexión de datos que se asoció con el UE remoto en la Tarea 2.
La dirección de AS1 a utilizar se obtuvo en la Tarea 1 o se proporcionó en el UE remoto (véase la Tarea 2 para una posible implementación).
Otra forma de garantizar que el UE remoto tenga restringido el acceso sólo al AS diana es que el UE remoto utilice un FQDN para llegar al AS diana. Si el UE remoto envía un FQDN que no coincide con el FQDN almacenado en el UE de retransmisión, el UE de retransmisión modifica el FQDN para que sea el almacenado en el UE de retransmisión con la ubicación del UE de retransmisión añadida, y el UE de retransmisión envía el FQDN en una solicitud, tal como una solicitud de Sistema de Nombres de Dominio (DNS, por sus siglas en inglés) a un servidor DNS.
La coincidencia de FQDN implica comparar la información de ubicación del UE de retransmisión incluida en la sintaxis del FQDN recibido del UE remoto, con la información de ubicación correspondiente de un FQDN almacenado en el UE de retransmisión.
Tarea 4: Si AS1 no puede completar la conexión segura establecida en respuesta al mensaje del UE de retransmisión, por ejemplo, porque AS1 se encuentra en una red visitada, entonces AS1 envía la información recibida en la Tarea 3 a AS2. AS2 se determina utilizando la segunda identidad del UE remoto recibida en la Tarea 3. Esta determinación se realiza utilizando la parte del dominio de la segunda identidad (por ejemplo, la segunda identidad tiene el formato de un identificador de acceso a la red (NAI, por sus siglas en inglés) [nombre de usuario@dominio] donde el dominio identifica a un operador de red. Si la parte del dominio de NAI recibida no es gestionada por AS1, AS1 dirige entonces el mensaje del UE de retransmisión a AS2.
Tarea 5: Si el UE remoto está autorizado a utilizar un UE de retransmisión, entonces AS2 crea una indicación que es o contiene la segunda identidad para el UE remoto que se enviará de vuelta a la Tarea 5 (por ejemplo, en un token). La indicación se almacena en la segunda identidad del UE remoto. AS2 envía el testigo u otro mensaje
En la Tarea 5, si el UE remoto no está autorizado a utilizar un UE de retransmisión o este UE de retransmisión específico, entonces AS2 crea una indicación de que el UE remoto no ha sido autorizado. AS2 envía, a AS1, un mensaje que contiene una indicación que puede indicar cualquiera o alguna combinación de lo siguiente:
a. el UE remoto falló la autenticación,
b. el UE remoto no puede utilizar un UE de retransmisión de Capa 2,
c. no se permite al UE remoto utilizar este UE de retransmisión de Capa 2 específico,
d. no se permite al UE remoto utilizar un UE de retransmisión en itinerancia,
e. el UE remoto no está autorizado a utilizar un UE de retransmisión conectado a esta RPLMN, o bien f. otra indicación.
Tenga en cuenta que AS2 y AS1 pueden ser la misma entidad o entidades diferentes.
La autorización para utilizar un UE de retransmisión puede determinarse utilizando alguno o ninguno de los siguientes elementos: una ubicación del UE remoto, una identidad del UE de retransmisión o una red (por ejemplo, RPLMN) a la que esté conectado el UE de retransmisión.
La indicación enviada por AS2 a AS1 puede basarse en alguno o ninguno de los siguientes elementos: una ubicación del UE de retransmisión, una identidad del UE de retransmisión o una red (por ejemplo, RPLMN) a la que esté conectado el UE de retransmisión.
Tarea 6: AS1 envía, al UE remoto, un mensaje que contiene una indicación que incluye la segunda identidad para el UE remoto (por ejemplo, token), o una indicación de que el UE remoto no puede utilizar el UE de retransmisión como UE de retransmisión de capa 2.
En respuesta a la recepción de la indicación de que el UE remoto no puede utilizar el UE de retransmisión como UE de retransmisión de Capa 2, el UE remoto puede realizar cualquiera de las siguientes acciones:
a. mostrar la indicación en una pantalla del UE remoto;
b. emitir un sonido audible;
c. si la indicación recibida indica que el UE remoto no está autorizado a utilizar este UE de retransmisión de Capa 2 específico, el UE remoto puede repetir el procedimiento de la tarea 1 si hay otro UE de retransmisión disponible;
d. si la indicación recibida indica que el UE remoto no está autorizado a utilizar este UE de retransmisión de Capa 2 específico, el UE remoto puede repetir el procedimiento de la tarea 1 si hay otro UE de retransmisión disponible, pero si el UE de retransmisión indica que el UE de retransmisión está conectado a la misma RPLMN, el UE remoto no procede con ninguna de las otras tareas.
Tarea 7: AS2 envía un mensaje al HSS que contiene cualquiera o alguna combinación de los siguientes elementos: una indicación que puede contener la segunda identidad del UE remoto, u otra información.
El HSS recibe el mensaje de AS2 y almacena, asigna o crea un enlace entre la indicación y la segunda identidad del UE remoto que se recibió en el mensaje de AS2.
Tarea 8: Si en la tarea 7 se recibe una indicación que contiene la segunda identidad del UE remoto, el UE remoto envía al UE de retransmisión un mensaje que contiene la segunda identidad del UE remoto que forma parte del token recibido en el mensaje del AS1.
Tarea 9: El mensaje de la Tarea 8 procedente del UE remoto es recibido por el UE de retransmisión en una capa de la pila de protocolos tal que el UE de retransmisión no interactúa con el mensaje. El UE de retransmisión pasa, al nodo de gestión de la movilidad, el mensaje recibido en la Tarea 8.
Tarea 10: En respuesta al mensaje de la Tarea 9 del UE de retransmisión, el nodo de gestión de la movilidad envía, al Nodo de Red 1, un mensaje que incluye cualquiera o alguna combinación de los siguientes elementos: la segunda identidad recibida en el mensaje de Tarea 9, y la identidad del UE de retransmisión.
El Nodo de Red 1 (por ejemplo, el HSS) recibe el mensaje de la Tarea 10. El HSS determina (por ejemplo, a partir de la sintaxis de la segunda identidad) que la segunda identidad incluida en el mensaje de la Tarea 10 es una ID temporal y determina si la segunda identidad está asignada a un perfil (por ejemplo, segundo perfil de identidad del UE remoto). Alternativamente, el HSS utiliza la segunda identidad recibida para recuperar un perfil de abonado asociado a la segunda identidad, por ejemplo, en la Tarea 7. Como parte de la recuperación del perfil, el HSS obtiene o crea vectores de autenticación asociados a la segunda identidad del UE remoto.
La determinación de la ID temporal puede ser por rango, por ejemplo, si la ID temporal tiene el formato de una IMSI, entonces los números específicos dentro de la estructura IMSI pueden significar que se trata de una ID temporal. Un ejemplo puede ser que el valor N (siendo N un número entero entre 0 y algún valor distinto de cero) en la estructura IMSI significa que la IMSI es temporal.
Tarea 11: En respuesta al mensaje de la Tarea 10, el HSS envía, al nodo de gestión de la movilidad, los vectores de autenticación determinados en la Tarea 10.
Tarea 12: En respuesta a los vectores de autenticación del HSS, el nodo de gestión de la movilidad envía los vectores de autenticación al UE de retransmisión.
Tarea 13: El UE de retransmisión envía los vectores de autenticación recibidos en la tarea 12 al UE remoto. Los vectores de autenticación constituyen un desafío de autenticación para el UE remoto.
Tarea 14: En respuesta a la solicitud de autenticación, el UE remoto envía, al UE de retransmisión, una respuesta de solicitud de autenticación.
Tarea 15: El UE de retransmisión envía, al nodo de gestión de la movilidad, la respuesta de desafío de autenticación recibida en la Tarea 14.
Obsérvese que en las Tareas 12, 13, 14 y 15, el UE de retransmisión recibe y envía de forma clara los mensajes comunicados entre el UE remoto y el nodo de gestión de la movilidad.
2.1.2, Comunicación con el servidor de aplicaciones
Las dos subsecciones siguientes contienen información más detallada sobre cómo realizar las tareas 3, 3b y 6 de la Figura 3. Un mecanismo es utilizar OAuth y el otro es utilizar EAP.
2.1.2.1, OAuth
Los ejemplos de cambios propuestos a TS 33.180 de 3GPP se exponen en la Tabla 2 a continuación (los cambios están subrayados) para utilizar OAuth. Las cifras de TS 33.180 de 3GPP se omiten para mayor claridad.
Tabla 2
Un ejemplo de solicitud de token para MCX Connect podría ser el siguiente.
EJEMPLO:
POST /as/token.oauth2 HTTP/1.1
Host: IdM.server.com:9031
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
grant type=authorization code&code=SplxlOBeZQQYbYS6WxSbIA&client id=myNativeApp&code er=0xl23456789abcdefSredirect uri=http://3gpp.mcptt/cb&Relay UE identity=user@domain rvice network of relay UE=mcc233mnc456&Location=41°24'12■2"N 2°10'26.5"E
B.3.1.4 Respuesta de token
Si la solicitud de token de acceso es válida y está autorizada, el servidor ldM devuelve un token de ID, un token de acceso y un token de actualización al cliente MCX; en caso contrario, mostrará un error. Un ejemplo de respuesta correcta podría ser el
siguiente:
EJEMPLO:
HTTP/1.1 200 OK
Contenz-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access token":"eyJhbGciOiJSUzIlNiJ9.eyJtY3B0dF9pZCI6ImFsaWNlQG9yZy5jb20iLCJleHAi
YxMjEslnNjb3BHjpbIm9wZW5pZCIsIjNncHA6bWNwdHQ6cHR0X3NlcnZlciJdLCJjbGllbnRfaWQiOiJt GllbnQifQ.XYIqai4YKSZCKRNMLipGC_5nV4BE791JpvjexWjIqqcqiEx6AmHHIRo0mhcxeCESrXei9krc hgF3szvgbwl8JRbFuv97XgepDLjEq4jL3Cbu4lQ9bOWdXAdFmeEbiB8wo_xggiGwv6IDRlb3TgAAsdjkRx OJSRmM7MKMcKhIug3BEkSC9-aXBTSIv5fAGN-ShDbPvHycBpj zKWXBvMIR5PaCg-9fwjELXZXdRwz8C6JbRM8aqzhdt4CVhQ3-Arip-S9CKd0tu-qhHfF2rvJDRlg8ZBiihdPH8mJs-qpTFep_ kON3mLO_g54xVmlMwNOXQA", "refresh_token":"Y7NSzUJuSOJp7G4SKpBKSOJVHIZxFbxqsqCIZhOEk9", "id_token":"eyJhbGciOiJSUzIINiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwiYXVkIjoibWNwdHRfY2xpZ NzljoiSWRNUy5zZXJ2ZXIuY29t0jkwMzEiLCJpYXQi0jE0NTM00TgxNTgsImV4cCI6MTQlMzQ50DQ10Cwi WQiOiJhbGljZUBvcmcuY29tln0.Dpn7AhIMaqMEggl2NYUUfJGSFJMPG8M21i9FLtPotDlHvwU2emBws8z noLqZ8ZF8tIhZlW7uuMbufF4Wsr7PAadZixz3CnV2wxFV9qR_VAl-0ccDTPukUsRHsic0SgZ3aIbcYKd6VsehFe_GDwfqysYzD7yPwCfPZo",
"token_type": "Bearer",
"expires_in": 7199
} "
El cliente MCX puede ahora validar al usuario con el token de ID y configurarse para el usuario (por ejemplo, extrayendo la ID de servicio MC del token de ID). A continuación, el cliente MCX utiliza el token de acceso para realizar solicitudes autorizadas a los servidores de recursos MCX (servidor MCPTT, servidor MCVideo, servidor MCData, KMS, etc.) en nombre del usuario final.
Anexo C (A modo informativo):
Flujo detallado de OpenlD connect
C.1 Flujo detallado para la autenticación y registro de usuarios MC mediante OpenlD Connect
La Figura D.1-1 muestra el flujo detallado para la Autenticación y Registro de Usuarios MC utilizando los mensajes de OpenID Connect como se describe en el anexo B.
[SE OMITE LA FIGURA D.1-1; A CONTINUACIÓN SE HACE REFERENCIA A LAS ETAPAS DE LA FIGURA D.1-1 DE LA NORMA]
Etapa 0 El UE se conecta a la red, establece la conectividad normal y configura la seguridad de la _________ red según se define en TS 33.401 de 3GPP [14]. En este punto se descubre la P-CSCF local
La Tabla 3 a continuación describe un flujo de ejemplo alternativo para utilizar OAuth.
Tabla 3
2.1.2.2, EAP
La Tabla 4 muestra ejemplos de cambios en TS 24.302 de 3GPP (el texto subrayado indica cambios) para utilizar EAP.
Tabla 4
2.1.3, Suministro de identidades de acceso al servidor de aplicaciones por parte del UE de retransmisión
A continuación se describen ejemplos de cómo se proporciona a un UE de retransmisión la identidad de un servidor de aplicaciones (por ejemplo, AS1).
2.1.3.1, Operación del UE
Lo que sigue se refiere a la Figura 6.
Tarea 602: El UE de retransmisión envía una solicitud a la red (por ejemplo, Conexión, Procedimiento IMS [por ejemplo, Registrar, Suscribir], etc.) que contenga una indicación de que el UE es un UE de retransmisión, por ejemplo, en una etiqueta PCO.
Tarea 604: El UE de retransmisión recibe una respuesta (a la solicitud) de la red (por ejemplo, Aceptar Conexión, 200 OK, Notificar, etc.) que contiene una indicación de la dirección (por ejemplo, APN, dirección IP, etc.) que se utilizará para acceder a las identidades del servidor de aplicaciones.
Aceptar Conexión puede contener la indicación en un campo OCP.
El mensaje 200 OK o Notificar es una indicación de la dirección del servidor de aplicaciones, tal como en un formato de ejemplo mostrado en la Tabla 5.
Tabla 5
En la Tabla 6 se presenta un ejemplo de implementación de PCO en el que las modificaciones propuestas a TS 24.008 de 3GPP se indican mediante el texto subrayado (texto añadido) y el texto tachado (texto suprimido).
Tabla 6
Cuando se incluye 0012H, la codificación de los servicios proporcionados para el servidor de acceso se puede encontrar en la Tabla 7 (el texto subrayado indica que se ha añadido a TS 24.008 de 3GPP)
Tabla 7
En la Tabla 7, la codificación para APN y la dirección del Servidor de Acceso se puede encontrar en la Tabla 1.
2.1.3.2, Operación del nodo de red
A continuación se describe la operación del nodo de red de la Figura 6.
Tarea 602 - El nodo de red (por ejemplo, MME, S-CSCF, P-GW, AMF, SMF, Servidor de Aplicaciones, etc.) recibe la petición del UE de retransmisión con una indicación de que es un UE de retransmisión.
Tarea 604 - Si el mensaje de la Tarea 602 contiene la indicación de que el UE es un UE de retransmisión y si el nodo de red está configurado con una dirección de un servidor de aplicaciones, el nodo de red incluye dicha dirección del servidor de aplicaciones en respuesta a la solicitud enviada al UE de retransmisión.
La dirección del servidor de aplicaciones puede estar en una base de datos externa, por ejemplo, HSS/HLR, y enviarse al nodo de red (por ejemplo, Centro de Conmutación Móvil (MSC, por sus siglas en inglés), MME, Función de control de estado de llamada - Servidora (S-CSCF, por sus siglas en inglés) a través de un mensaje (por ejemplo, Inserción de Datos del Suscriptor según TS 29.002 de 3GPP o TS 29.272 de 3GPP)
Sección 2.2, Detalles de la Implementación 2
A continuación se describen varias opciones que pueden utilizarse con la
Implementación 2, incluyendo las Opciones A, B y C.
2.2.1, Opción A
La Figura 7 muestra la Opción A de la Implementación 2.
El etiquetado de las flechas en la Figura 7 y la descripción a continuación está desordenado a propósito, por ejemplo, la Tarea 4b se produce después de la Tarea 5e. Se han elegido para que coincidan con la numeración de la sección 1.2.
Tarea 1: Véase la sección 2.1.1 Tarea 1.
Tarea 2: Véase la sección 2.1.1 Tarea 2. La tarea de crear un contexto PDP y una conexión PDN con la red incluye la tarea de Registro (Conexión).
Tareas 3, 3b: Véase la sección 2.1.1 Tareas 3) y 3b, Con más aclaraciones a continuación.
El UE remoto envía, a AS1, un mensaje de registro (por ejemplo, Conexión, etc.) que contiene uno o varios de los siguientes elementos: un ID de usuario privado, una primera dirección PDN del UE remoto (por ejemplo, en un mensaje de Gestión de Sesiones del Sistema Evolucionado de Paquetes (ESM, por sus siglas en inglés)), la ubicación del UE de retransmisión u otra información.
Tarea 4a: AS1 puede eliminar o cambiar la primera dirección PDN, si se recibe una, en el mensaje de la Tarea 3b. Si la primera dirección PDN se incluye en el mensaje del UE remoto, la primera dirección PDN puede sustituirse y establecerse en una que esté configurada en AS1 (una segunda dirección PDN) cuando el mensaje Conexión se envíe a MME.
La Figura 8 muestra posibles pilas de protocolos en el UE remoto, AS1 y MME, que muestran cómo la Tarea 3b puede interconectarse con la Tarea 4a y en las subsiguientes interacciones entre UE remoto <-> AS1 <-> MME.
La pila de protocolos del UE remoto incluye una capa de nivel 1 (L1), una capa de nivel 2 (L2), una capa IP, una capa de seguridad IP (IPSec, por sus siglas en inglés), una capa de aplicaciones y una capa NAS. El AS1 incluye una primera pila de protocolos para comunicarse con el UE remoto, donde la primera pila de protocolos incluye una capa L1, una capa L2, una capa IP, una capa IPSec y una capa de aplicaciones. AS1 incluye además una segunda pila de protocolos para comunicarse con MME, donde la segunda pila de protocolos incluye una capa L1, una capa L2, una capa de Protocolo de Control de Transmisiones de Corrientes (SCTP, por sus siglas en inglés)4P y una capa de protocolo de aplicaciones S1 (S1-AP). AS1 también incluye una función de retransmisión 802 para retransmitir entre la primera y la segunda pila de protocolos de AS1.
La MME tiene una pila de protocolos que incluye una capa L1, una capa L2, una capa SCTP/IP, una capa S1-AP y una capa NAS.
Las interacciones entre UE remoto <-> AS1 <-> MME incluyen que AS1 realice cualquiera de las siguientes acciones:
• Cuando AS1 recibe un mensaje del UE remoto, la función de retransmisión 802 de AS1 saca el mensaje NAS de la capa de Aplicación e inserta el mensaje NAS en un mensaje S1-AP y envía el mensaje S1-AP a la MME.
• Cuando AS1 recibe un mensaje de MME, AS1 extrae el mensaje NAS del mensaje S1 -AP y envía el mensaje al UE remoto.
Tarea 4a: En respuesta al mensaje de Registro de la Tarea 3b de la Figura 7, AS^ envía a una MME 702 un mensaje de Registro (por ejemplo, Conexión, Actualización de Ubicación, Actualización de Área de Enrutamiento, Actualización de Área de Seguimiento, etc.) que contiene cualquiera o alguno de los siguientes elementos: una ID privada de usuario, la segunda dirección PDN, u otra información. La MME 702 es la MME "antiguo" del UE remoto, es decir, la MME con la que el UE remoto se asociará inicialmente en función de la ubicación del UE remoto, por ejemplo.
Las características de la segunda dirección PDN son tales que si el UE remoto intenta utilizar la conexión PDN correspondiente a la segunda dirección PDN para enviar tráfico de datos, el tráfico fallará.
La ubicación del UE de retransmisión puede utilizarse para determinar la MME 702 a la que el AS1 debe enviar el mensaje de registro. Puede haber una coincidencia en el AS1 entre las ubicaciones y las MME.
Tarea 5 a)i): La MME 702 solicita vectores de autenticación al HSS utilizando la ID privada de usuario recibida en la Tarea 3b.
Tarea 5a)ii): En respuesta a la solicitud de la Tarea 5 a)i) de la MME 702, el HSS envía los vectores de autenticación a la MME 702.
Tarea 5b: La MME 702 envía un desafío de autenticación a AS1, por ejemplo, en una Solicitud de Autenticación de NAS.
Tarea 5c: En respuesta al desafío de autenticación, AS1 envía el desafío de autenticación al UE remoto.
Tarea 5d: En respuesta al desafío de autenticación, el UE remoto envía una respuesta de desafío de autenticación a AS1.
Tarea 5e: AS1 envía la respuesta de desafío de autenticación a la MME 7702, por ejemplo, en una respuesta de autenticación de NAS.
Tarea 4b: En respuesta a la respuesta de desafío de autenticación, la MME 702 envía, a AS1, una Aceptación de Conexión (por ejemplo, Aceptación de Registro, Aceptación de Ubicación, Aceptación de Actualización de Área de Enrutamiento, Aceptación de Actualización de Área de Seguimiento, etc.) con una ID temporal (por ejemplo, GUTI, TMSI, etc.). En la Opción A, la MME 702 asigna la ID temporal del<u>E remoto.
Tarea 6: AS1 envía al UE remoto la ID temporal recibida en la Tarea 4b desde la MME 702.
Tarea 8: Tras recibir la ID temporal, el UE remoto envía al UE de retransmisión un mensaje de registro que contiene la ID temporal. El mensaje de registro puede incluir una Conexión, una Actualización de Ubicación, una Actualización de Área de Enrutamiento, una Actualización de Área de Seguimiento, etc.
Tarea 9: Véase la sección 2.1.1 Tarea 9. Obsérvese que en la Figura 7, el mensaje de registro puede ser reenviado por el UE de retransmisión a una nueva MME 704, que puede ser idéntica o diferente de la MME 702 antigua.
Tareas 9a, 9b: La nueva MME 704 obtiene la información de contexto de la antigua MME 702 asociada con el UE remoto utilizando las normas existentes.
Tareas 10-15) Véase la sección 2.1.1, Tareas 10-15, respectivamente.
2.2.2, Opción B
La Figura 9 muestra la Opción B de la Implementación 2.
Obsérvese en la Figura 9 que AS1 puede implementarse con una ePDG y un servidor AAA. La ePDG y el servidor AAA pueden formar parte del mismo nodo de red o incluirse en nodos de red independientes. Adicionalmente, en algunos ejemplos, una MME también puede combinarse con AS1, así como la P-GW.
La Figura 10 representa las posibles pilas de protocolos cuando se combinan la ePDG y el servidor AAA. Como se muestra en la Figura 10, el UE remoto tiene una pila de protocolos que incluye una capa L1, una capa L2, una capa IP y una capa IKEv2rEAP. AS1 incluye una primera pila de protocolos para comunicarse con el UE remoto. La primera pila de protocolos incluye una capa L1, una capa L2, una capa IP y una capa IKEv2rEAP.
Una segunda pila de protocolos de AS1 que se comunica con una MME incluye una capa L1, una capa L2, una capa SCTP/IP y una capa NAS. Una pila de protocolos de la MME incluye una capa L1, una capa L2, una capa SCTP/IP y una capa NAS.
En la Figura 10, cuando AS1 recibe un mensaje de IKE o EAP, ASI interconectará el contenido del mensaje de IKE o EAP en un mensaje NAS. Este interfuncionamiento puede implicar cualquiera de los siguientes elementos:
a) AS1 puede tomar un parámetro de un mensaje EAP y convertirlo en un parámetro equivalente, por ejemplo, IMSI se codifica como NAI y se convierte en un valor numérico donde cada número está representado por 4 bits.
b) AS1 puede tomar un parámetro de un mensaje EAP y asignar el parámetro a un parámetro equivalente. Cuando AS1 recibe un mensaje NAS en sentido inverso, AS1 realiza la conversión inversa o la asignación a un mensaje EAP.
Lo que sigue se refiere a las tareas de la Figura 9.
Tarea 1: Véase la sección 2.1.1 Tarea 1.
Tarea 2: Véase la sección 2.1.1 Tarea 2)
Tarea 2a: El UE remoto y la ePDG intercambian un primer par de mensajes, conocido como IKE_SA_INIT, en los que la ePDG y el UE negocian asociaciones criptográficas, intercambian nonces y realizan un intercambio Diffie_HeIIman de valores Diffie_Hellman.
Tareas 3, 3b: El UE remoto envía, en un primer mensaje (mensaje de solicitud IKE_AUTH) de la fase IKE_AUTH, una identidad de usuario tal como la ID privada de usuario (en la carga útil IDi del primer mensaje), información APN (en la carga útil IDr del primer mensaje), y la ubicación del UE remoto (codificada como parte de la identidad de usuario). El mensaje de solicitud IKE_AUTH también incluye información de asociación de seguridad para que el UE remoto comience la negociación de las asociaciones de seguridad hijas.
El UE remoto envía la carga útil de configuración (CFG_REQUEST) dentro del mensaje de solicitud IKE_AUTH para obtener una dirección IP IPv4 y/o IPv6 de origen y/o una dirección de Agente Domiciliario. El UE remoto omite el parámetro AUTH con el fin de indicar a la ePDG que el UE remoto desea utilizar EAP sobre IKEv2. La identidad del usuario se ajusta al formato del identificador de acceso a la red (NAI) especificado en TS 23.003, y contiene la IMSI o el seudónimo, tal como se define para EAP-AKA (Autenticación y Acuerdo de Claves) en la Solicitud de Comentarios (RFC, por sus siglas en inglés) 4187.
Nota: Véanse las descripciones de las Tareas 3 y 3b en otra parte de esta descripción sobre cómo el UE de retransmisión puede garantizar que los mensajes de las Tareas 2a, 3 y 3b sean guiados al AS1 correcto.
Tarea 3c: En respuesta al mensaje de solicitud IKE_AUTH, la ePDG envía un mensaje de solicitud de autenticación y autorización al servidor AAA de 3GPP (parte del Nodo de Red 1). El mensaje de solicitud de autenticación y autorización contiene la identidad del usuario, la ubicación del UE remoto y el APN incluido en el mensaje de solicitud IKE_AUTH recibido. El UE remoto utiliza el NAI definido de acuerdo con la cláusula 19.3 de TS 23.003 de 3GPP, y el servidor AAA de 3GPP identifica, basándose en la parte del sector del NAI, que se está realizando una autenticación y autorización combinadas para el establecimiento del túnel con una ePDG que sólo permite EAP-AKA.
Tarea 4a: A continuación, el servidor AAA realiza el interfuncionamiento entre el mensaje EAP de la Tarea 3c y un mensaje NAS que se envía a una MME 702. El mensaje NAS puede incluir un mensaje de Registro, un mensaje de Conexión, un mensaje de Actualización de Ubicación, un mensaje de Actualización de Área de Enrutamiento, un mensaje de Actualización de Área de Seguimiento, etc. El servidor AAA de 3GPP toma la identidad del usuario en el mensaje de Solicitud de Autenticación y Autorización recibido de la ePDG, y genera una ID temporal (representada como ID1 de usuario). El servidor AAA también crea una asignación entre la identidad del usuario y la ID temporal (ID1 de usuario), e incluye la ID temporal (ID1 de usuario) en el mensaje NAS de la Tarea 4a enviado desde el servidor AAA a la MME 702. El mensaje NAS también puede incluir un APN, que puede tomarse de la Tarea 3c o modificarse como se describe en la Tarea 4a de la sección 2.2.1 (para la Opción A anterior).
Véase la Tarea 6, sección 2.2.1, para otros posibles procedimientos.
Tarea 5a)i: La MME 702 envía una solicitud de vectores de autenticación para la ID temporal (ID1 de usuario) al servidor AAA.
Tarea 5a)1: El servidor AAA utiliza la ID temporal recibida (ID1 de usuario) para encontrar la identidad del usuario (véase la Tarea 4a anterior sobre cómo se crea esta asignación entre la ID temporal (ID1 de usuario) y la identidad del usuario). El servidor AAA envía, a un HSS (parte del Nodo de Red 1), una solicitud de vectores de autenticación para la identidad del usuario.
Tarea 5a)2: En respuesta a la solicitud de vectores de autenticación, el HSS envía, al servidor AAA, un mensaje que contiene vectores de autenticación. El servidor AAA recibe los vectores de autenticación y los compara con la identidad del usuario.
Tarea 5a)ii: El servidor AAA envía, a la MME 702, un mensaje que contiene los vectores de autenticación recibidos.
Tarea 5b: La MME 702, en respuesta a la recepción de los vectores de autenticación del servidor AAA, envía un mensaje de solicitud de autenticación NAS (un desafío de autenticación) al servidor AAA.
Tarea 5b)1: El servidor AAA interconecta el mensaje de solicitud de autenticación NAS con un mensaje de solicitud/desafío de EAP. El servidor AAA inicia el desafío de autenticación enviando el desafío de autenticación en un mensaje de respuesta de autenticación y autorización a la ePDG, que responde a la autenticación y autorización enviada por la ePDG al servidor AAA. El servidor AAA también almacena los vectores de autenticación que se utilizaron en el mensaje de solicitud de autenticación NAS para que el servidor AAA pueda determinar posteriormente qué conjunto de vectores de autenticación se utilizó para desafiar al UE remoto. Esta información de las Tareas 5b)1 y 4b)1 (que se tratan más adelante) se utiliza para crear el material de claves correctas.
Tarea 5c: La ePDG responde al mensaje de respuesta de autenticación y autorización enviando un mensaje de respuesta IKE_AUTH al UE remoto, donde el mensaje de respuesta IKE_AUTH responde al mensaje de respuesta IKE_AUTH de las Tareas 3 y 3b. El mensaje de respuesta IKE_AUTH contiene la identidad de la ePDG, un certificado y un parámetro AUTH para proteger el mensaje previo que la ePDG envió al UE remoto (en el intercambio IKE_SA_INIT de la Tarea 2a). El mensaje EAP recibido del servidor AAA (solicitud de EAP/desafío de AKA) se incluye en el mensaje de respuesta IKE_AUTH para iniciar el procedimiento EAP sobre IKEv2.
Tarea 5d: En respuesta al mensaje de respuesta IKE_AUTH, el UE remoto verifica los parámetros de autenticación y responde al desafío de autenticación enviando, a la ePDG, otro mensaje de solicitud IKE_AUTH. El mensaje de solicitud IKE_AUTH de la Tarea 5d incluye un mensaje EAP (respuesta de EAP/desafío de AKA) que contiene la respuesta del UE remoto al desafío de autenticación.
Tarea 5d)1: La ePDG reenvía el mensaje de repuesta de EAP/desafío de AKA al servidor AAA en un mensaje de solicitud de autenticación y autorización.
Tarea 5e: El servidor AAA toma la respuesta de desafío de autenticación de la Tarea5d)1 e incluye la respuesta de desafío de autenticación en un mensaje de respuesta de autenticación a la MME 702.
Tarea 4b: Véase la sección 2.2.1, Tarea 4b.
Tarea 4b)1: El servidor AAA recibe el mensaje Aceptar Conexión de la MME 702 (Tarea 4b), e interconecta el mensaje Aceptar Conexión en un mensaje de Éxito de EAP. El servidor AAA toma una ID temporal (por ejemplo, GUTI) de la Tarea 4b y lo incluye en el mensaje de Éxito de EAP.
Si todas las comprobaciones resultan satisfactorias, el servidor AAA envía, a la ePDG, la Respuesta de Autenticación y Autorización final (con un código de resultado que indica éxito) incluyendo la información de autorización de servicio relevante, GUTI, el éxito de EAP y el material de claves para ePDG. El material de claves incluye una Clave Maestra de Sesión (MSK, por sus siglas en inglés) generada durante el procedimiento de autenticación. Cuando las interfaces SWm y SWd entre la ePDG y el servidor AAA se implementan utilizando Diámetro, la MSK se encapsula en EAP-Clave Maestra de Sesión-AVP, tal y como se define en RFC 4072].
Tarea 6: La ePDG envía, al UE remoto, un mensaje de respuesta IKE_Auth que contiene la ID temporal (por ejemplo, GUTI). El mensaje de respuesta IKE_Auth responde al mensaje de solicitud IKE_Auth de la Tarea 5d.
Tareas 8, 9, 9a, 9b, 10-15: Véase la sección 2.2.1 Tareas 8, 9, 9a, 9b, 10-15, respectivamente.
2.2.3, Opción C
La Figura 11 muestra la Opción C de la Implementación 2.
En la opción C, el UE remoto utiliza procedimientos S2b no 3GPP para autenticarse con una ePDG. Este procedimiento de autenticación proporciona una identidad que el UE remoto puede utilizar para registrarse en la red principal a través de un UE de retransmisión.
Tareas 1,2, 2a, 3, 3c, 5a)1, 5a)2, 5b) 1, 5c, 5d, 5d)1, 4b)1, Véase la sección 2.2.2 Tareas 1,2, 2a, 3, 3c, 5a)1, 5a)2, 5b)1, 5c, 5d, 5d)1,4b)1, respectivamente.
Tarea 6: Véase la sección 2.2.2 Tarea 6. Adicionalmente, cuando la ePDG envía el mensaje de respuesta IKE_AUTH de la Tarea 6, la ePDG también asigna o adjudica una ID temporal (por ejemplo, que tenga el formato de una IMSI, etc.). La ePDG crea un enlace entre la identidad de usuario recibida en la Tarea 3 y la ID temporal (por ejemplo, IMSI, etc.).
Tarea 8: Véase a sección 2.2.2 Tarea 8. El UE envía, al UE de retransmisión, un mensaje, por ejemplo, Conexión, Actualización de Área de Seguimiento, Actualización de Ubicación, etc., que contiene la ID temporal recibida en la Tarea 6.
Tarea 9: Véase la sección 2.2.2 Tarea 9.
Tarea 10: La MME 702 envía, al servidor AAA, una solicitud de vectores de autenticación para la ID temporal recibida en la Tarea 9.
Tenga en cuenta que el valor de la ID temporal es tal que el enrutamiento de la solicitud de vectores de autenticación termina en la entidad que asignó esta ID temporal (que, en este caso, es el servidor AAA).
Tarea 10a: Al recibir una solicitud de vectores de autenticación para la ID temporal recibida en la Tarea 10, el servidor AAA utiliza la ID temporal para determinar si existe una asignación a otra identidad (por ejemplo, la identidad privada del UE remoto). Si existe otra identidad (es decir, la identidad de usuario recibida en la Tarea 3), el servidor AAA utiliza la otra identidad para recuperar vectores de autenticación. El servidor AAA envía una solicitud de vectores de autenticación para la otra identidad al HSS
Tarea 10b: El HSS envía los vectores de autenticación solicitados al servidor AAA.
Tarea 11: El servidor AAA envía los vectores de autenticación a la MME 702.
Ejemplo de sistema
La Figura 12 es un diagrama de bloques de un nodo de comunicación 1200, que puede ser cualquiera de un UE remoto, un UE de retransmisión, un servidor de aplicaciones, un nodo de gestión de la movilidad, un nodo de red o cualquier otro tipo de nodo que pueda participar en los procedimientos según la presente descripción.
El nodo de comunicación 1200 incluye un procesador 1202 (o múltiples procesadores). Un procesador puede incluir un microprocesador, un núcleo de un microprocesador multinúcleo, un microcontrolador, un circuito integrado programable, una matriz de puertas programable u otro circuito de procesamiento de hardware.
El nodo de comunicación 1200 también incluye un medio de almacenamiento legible por máquina o por ordenador no transitorio 1204 que almacena instrucciones legibles por máquina 1206 que son ejecutables en un procesador (es decir, uno o más procesadores 1202) para realizar diversas tareas como se analiza en la presente descripción. El nodo de comunicación 1200 también incluye una interfaz de comunicación 1208 para realizar comunicaciones por cable o inalámbricas. La interfaz de comunicación 1208 puede incluir un controlador de interfaz de red, un transceptor de radio, etc.
El medio de almacenamiento 1204 puede incluir cualquiera o alguna combinación de los siguientes: un dispositivo de memoria semiconductor tal como una memoria de acceso aleatorio dinámica o estática (una DRAM o SRAM), una memoria de sólo lectura borrable y programable (EPROM), una memoria de sólo lectura eléctricamente borrable y programable (EEPROM) y una memoria flash; un disco magnético tal como un disco fijo, flexible y extraíble; otro medio magnético incluyendo cinta; un medio óptico tal como un disco compacto (CD) o un disco de vídeo digital (DVD); u otro tipo de dispositivo de almacenamiento. Obsérvese que las instrucciones mencionadas anteriormente pueden proporcionarse en un medio de almacenamiento legible por ordenador o legible por máquina o, alternativamente, pueden proporcionarse en múltiples medios de almacenamiento legibles por ordenador o legibles por máquina distribuidos en un gran sistema que posiblemente tenga varios nodos. Dicho medio o medios de almacenamiento legibles por ordenador o legibles por máquina se consideran parte de un artículo (o artículo de fabricación). Un artículo o artículo de fabricación puede referirse a cualquier componente individual o múltiple fabricado. El medio o medios de almacenamiento pueden estar ubicados en la máquina que ejecuta las instrucciones legibles por máquina o ubicados en un sitio remoto desde el que se pueden descargar las instrucciones legibles por máquina a través de una red para su ejecución.
Claims (14)
1. Un procedimiento realizado por un equipo de usuario, UE, remoto, que comprende las etapas de:
enviar una identidad privada del UE remoto y una indicación a un servidor de aplicaciones de que el UE remoto debe utilizar un UE de retransmisión para acceder a una red;
recibir del servidor de aplicaciones, una identidad temporal del UE remoto diferente de la identidad privada del UE remoto;
utilizar la identidad temporal para registrarse en la red con el fin de autenticar al UE remoto; y como parte del registro en la red:
enviar al UE de retransmisión un mensaje de conexión que contenga la identidad temporal del UE remoto; el mensaje de conexión hará que un nodo de gestión de la movilidad de la red envíe una solicitud de información de autenticación a un nodo de red que haya recibido, del servidor de aplicaciones, la identidad temporal del UE remoto;
recibir del nodo de red la información de autenticación; y
responder a la información de autenticación para realizar una autenticación del UE remoto en la red.
2. El procedimiento según la reivindicación 1, que comprende además:
recibir del UE de retransmisión información del UE de retransmisión,
donde la indicación comprende la información del UE de retransmisión,
donde, opcionalmente, la información del UE de retransmisión se selecciona de entre una identidad del UE de retransmisión, una red a la que está conectado el UE de retransmisión y una ubicación del UE de retransmisión.
3. El procedimiento según la reivindicación 1 o 2, donde el UE remoto establece un túnel, a través del UE de retransmisión, con el servidor de aplicaciones para realizar el envío y la recepción,
donde la tunelización se basa opcionalmente en que el UE de retransmisión tiene una conexión que sólo permite el acceso al servidor de aplicaciones.
4. El procedimiento según cualquier reivindicación anterior, donde la identidad temporal es asignada por el servidor de aplicaciones o un nodo de gestión de la movilidad.
5. El procedimiento según cualquier reivindicación anterior, que comprende además:
establecer una conexión segura con el servidor de aplicaciones, donde el envío y la recepción se realizan en la conexión segura.
6. El procedimiento según cualquier reivindicación anterior, donde el envío y la recepción utilizan un protocolo de autenticación extensible, EAP, o un protocolo OAuth.
7. Un equipo de usuario, UE, de retransmisión, que comprende:
una interfaz inalámbrica para comunicarse de forma inalámbrica; y
al menos un procesador configurado para:
asociarse con un UE remoto;
establecer una conexión con una red para proporcionar conectividad a un servidor de aplicaciones; retransmitir, a través de la conexión establecida, un paquete entre el UE remoto y el servidor de aplicaciones, el paquete enviado en una conexión segura entre el UE remoto y el servidor de aplicaciones y que contiene una identidad temporal del UE remoto diferente de una identidad privada del UE remoto; y
retransmitir, a través de la conexión establecida, mensajes de conexión y autenticación entre el UE remoto y el servidor de aplicaciones, donde los mensajes de conexión y autenticación contienen la identidad temporal del UE remoto y
hacer que un nodo de gestión de la movilidad de la red envíe una solicitud de información de autenticación a un nodo de red que haya recibido, del servidor de aplicaciones, la identidad temporal del UE remoto.
8. El UE de retransmisión según la reivindicación 7, donde el establecimiento de la conexión con la red utiliza una identidad del servidor de aplicaciones,
donde, opcionalmente, el al menos un procesador está configurado para:
enviar un primer mensaje a la red, conteniendo el primer mensaje una indicación del UE de retransmisión; recibir, desde la red, un segundo mensaje en respuesta al primer mensaje, conteniendo el segundo mensaje la identidad del servidor de aplicaciones.
9. Un servidor de aplicaciones que comprende:
una interfaz de comunicación; y
al menos un procesador acoplado a la interfaz de comunicación y configurado para:
recibir, de un equipo de usuario, UE, remoto, una identidad privada del UE remoto y una indicación de que el UE remoto debe utilizar un UE de retransmisión para acceder a una red; y
enviar, al UE remoto, una identidad temporal del UE remoto , la identidad temporal diferente de la identidad privada y para su uso por el UE remoto en la autenticación en la red, donde la identidad temporal se incluye en los mensajes de conexión y autenticación entre el UE remoto y el servidor de aplicaciones que hacen que un nodo de gestión de la movilidad de la red envíe una solicitud de información de autenticación a un nodo de red que ha recibido, del servidor de aplicaciones, la identidad temporal del UE remoto.
10. El servidor de aplicaciones según la reivindicación 9, donde la indicación se comunica utilizando una transmisión de mensajes según un primer protocolo.
11. El servidor de aplicaciones según la reivindicación 10, donde el al menos un procesador está configurado para:
enviar una solicitud a un nodo de gestión de la movilidad para la identidad temporal del UE remoto, la solicitud enviada en la transmisión de mensajes según un segundo protocolo diferente del primer protocolo, donde, opcionalmente, el primer protocolo es uno de un Protocolo de Autenticación Extensible, EAP, o un Estrato de Acceso a Red, NAS, sobre un Protocolo de Internet y el segundo protocolo es un protocolo NAS.
12. El servidor de aplicaciones según la reivindicación 11, donde el al menos un procesador está configurado para:
recibir de la red un desafío de autenticación en la transmisión de mensajes según el segundo protocolo; enviar, al UE remoto, el desafío de autenticación en la transmisión de mensajes según el primer protocolo recibir, del EU remoto, una respuesta de desafío de autenticación en la transmisión de mensajes según el primer protocolo;
enviar, a la red, la respuesta de desafío de autenticación en la transmisión de mensajes según el segundo protocolo;
recibir, de la red, una respuesta a la solicitud, siendo la respuesta en la transmisión de mensajes según el segundo protocolo e incluyendo la identidad temporal; y
enviar, al UE remoto, la identidad temporal en la transmisión de mensajes según el primer protocolo.
13. El servidor de aplicaciones según la reivindicación 11 o 12, donde el servidor de aplicaciones es un primer servidor de aplicaciones, y donde el al menos un procesador está configurado para:
recibir, del UE remoto, una solicitud para establecer una conexión segura entre el UE remoto y el primer servidor de aplicaciones;
en respuesta a la determinación de que el primer servidor de aplicaciones no puede establecer la conexión segura, enviar información asociada con la solicitud a un segundo servidor de aplicaciones;
recibir, del segundo servidor de aplicaciones, la identidad temporal.
14. El servidor de aplicaciones según cualquiera de las reivindicaciones 9 a 13, donde el servidor de aplicaciones comprende una función de interfuncionamiento no 3GPP, N3IWF, de una red 5G o una pasarela de paquetes de datos evolucionada, ePDG.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US15/725,563 US10631224B2 (en) | 2017-10-05 | 2017-10-05 | Authenticating user equipments through relay user equipments |
| PCT/US2018/053913 WO2019070668A1 (en) | 2017-10-05 | 2018-10-02 | AUTHENTICATION OF USER EQUIPMENTS THROUGH RELAY USER EQUIPMENTS |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2971007T3 true ES2971007T3 (es) | 2024-06-03 |
Family
ID=65993633
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES18864795T Active ES2971007T3 (es) | 2017-10-05 | 2018-10-02 | Autenticación de equipos de usuario a través de equipos de usuario de retransmisión |
Country Status (5)
| Country | Link |
|---|---|
| US (2) | US10631224B2 (es) |
| EP (1) | EP3679655B1 (es) |
| CN (2) | CN116033420B (es) |
| ES (1) | ES2971007T3 (es) |
| WO (1) | WO2019070668A1 (es) |
Families Citing this family (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10701739B2 (en) * | 2015-09-30 | 2020-06-30 | Lg Electronics Inc. | Call transmitting/receiving method in wireless communication system and device for same |
| ES2976088T3 (es) * | 2016-01-22 | 2024-07-23 | Malikie Innovations Ltd | Determinación del nombre del punto de acceso para servicios de misión crítica |
| CN109561429B (zh) * | 2017-09-25 | 2020-11-17 | 华为技术有限公司 | 一种鉴权方法及设备 |
| US10631224B2 (en) * | 2017-10-05 | 2020-04-21 | Blackberry Limited | Authenticating user equipments through relay user equipments |
| WO2019097499A1 (en) * | 2017-11-20 | 2019-05-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Security gateway selection in hybrid 4g and 5g networks |
| CN111480353B (zh) * | 2017-12-18 | 2023-10-27 | 皇家Kpn公司 | 用于在远程ue与电信网络之间建立信令连接的方法和设备 |
| US10869255B2 (en) * | 2018-06-22 | 2020-12-15 | T-Mobile Usa, Inc. | Telecommunications between remote terminal and relay terminal |
| US12238076B2 (en) * | 2018-10-02 | 2025-02-25 | Arista Networks, Inc. | In-line encryption of network data |
| CH715441B1 (de) * | 2018-10-09 | 2024-08-15 | Legic Identsystems Ag | Verfahren und Vorrichtungen zum Kommunizieren zwischen einer Internet-der-Dinge-Vorrichtung und einem entfernten Computersystem. |
| US11218438B2 (en) * | 2019-04-12 | 2022-01-04 | Huawei Technologies Co., Ltd. | System, apparatus and method to support data server selection |
| CN111818516B (zh) * | 2019-04-12 | 2022-10-18 | 华为技术有限公司 | 认证方法、装置及设备 |
| WO2021029512A1 (ko) * | 2019-08-09 | 2021-02-18 | 엘지전자 주식회사 | 어플리케이션 서버의 변경에 관련된 통신 |
| EP4021047B1 (en) * | 2019-08-19 | 2026-03-25 | LG Electronics Inc. | Authentication for relay |
| US12452651B2 (en) | 2019-10-04 | 2025-10-21 | Samsung Electronics Co., Ltd. | Method and device for activating 5G user |
| WO2021089903A1 (en) * | 2019-11-06 | 2021-05-14 | Nokia Technologies Oy | Tethering service provision |
| CN113038628B (zh) * | 2019-12-09 | 2023-04-25 | 维沃移动通信有限公司 | 中继参数的配置方法、终端设备和网络侧设备 |
| US11812481B2 (en) * | 2020-03-06 | 2023-11-07 | Qualcomm Incorporated | Layer 2 relay unicast link setup |
| EP4133767B1 (en) * | 2020-04-07 | 2025-07-23 | Apple Inc. | Tracking area identifier (tai) change during authentication request processing |
| JP7556036B2 (ja) * | 2020-04-07 | 2024-09-25 | 中興通訊股▲ふん▼有限公司 | サイドリンク中継通信に関するシグナリング伝送のためのシステムおよび方法 |
| US20230319921A1 (en) * | 2020-10-13 | 2023-10-05 | Peng Cheng | Protocol stacks and bearer modeling for rsu assisted uu connectivity |
| WO2022120653A1 (zh) * | 2020-12-09 | 2022-06-16 | 华为技术有限公司 | 一种路由方法、装置以及系统 |
| US20240056446A1 (en) * | 2020-12-15 | 2024-02-15 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods, entities and computer readable media for non-3gpp access authentication |
| CN114650581B (zh) * | 2020-12-18 | 2024-08-20 | 维沃移动通信有限公司 | 中继通信方法及装置 |
| KR102891938B1 (ko) * | 2021-03-04 | 2025-11-28 | 삼성전자주식회사 | 전자 장치 및 전자 장치에서 ims 기반의 콜을 처리하는 방법 |
| US11620363B1 (en) | 2021-03-15 | 2023-04-04 | SHAYRE, Inc. | Systems and methods for authentication and authorization for software license management |
| US11632362B1 (en) * | 2021-04-14 | 2023-04-18 | SHAYRE, Inc. | Systems and methods for using JWTs for information security |
| US11621830B1 (en) | 2021-06-28 | 2023-04-04 | SHAYRE, Inc. | Systems and methods for facilitating asynchronous secured point-to-point communications |
| CN115567934A (zh) * | 2021-06-30 | 2023-01-03 | 华为技术有限公司 | 一种认证方法及通信装置 |
| WO2023003452A1 (ko) * | 2021-07-21 | 2023-01-26 | 엘지전자 주식회사 | 다중 경로에 기초한 통신에서의 페이징 |
| CN114339753B (zh) * | 2021-12-31 | 2024-11-29 | 中国电信股份有限公司 | 通信数据处理方法、系统、电子设备和可读存储介质 |
| CN117676761A (zh) * | 2022-08-22 | 2024-03-08 | 中国电信股份有限公司 | 中继组网方法、装置、电子设备和计算机可读存储介质 |
| CN115459972B (zh) * | 2022-08-26 | 2024-04-16 | 西安电子科技大学 | 基于多无人机中继的安全匿名核心网访问方法 |
| EP4333543A1 (en) * | 2022-08-30 | 2024-03-06 | British Telecommunications public limited company | Telecommunications network and a method of operating a telecommunications network |
| WO2024092529A1 (en) * | 2022-11-01 | 2024-05-10 | Nokia Shanghai Bell Co., Ltd. | Determining authentication credentials for a device-to-device service |
Family Cites Families (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6236365B1 (en) * | 1996-09-09 | 2001-05-22 | Tracbeam, Llc | Location of a mobile station using a plurality of commercial wireless infrastructures |
| EP1692901B1 (en) * | 2003-12-13 | 2007-12-05 | Telefonaktiebolaget LM Ericsson (publ) | A system, arrangement and a method for handling connection of a mobile station moving in communications systems supporting communication of data |
| US7818580B2 (en) * | 2005-08-09 | 2010-10-19 | International Business Machines Corporation | Control of port based authentication protocols and process to support transfer of connection information |
| AU2007204558B2 (en) | 2006-01-10 | 2011-03-03 | Blackberry Limited | System and method for routing an incoming call to a proper domain in a network environment including IMS |
| CN1859098A (zh) | 2006-03-08 | 2006-11-08 | 华为技术有限公司 | 在无线接入系统中实现eap认证中继的方法 |
| US8223716B2 (en) * | 2006-12-05 | 2012-07-17 | Toshiba America Research, Inc. | Assisted proactive IP address acquisition |
| JP5076491B2 (ja) * | 2006-12-27 | 2012-11-21 | 富士通株式会社 | メッセージ着信方法、認証サーバ、移動ネットワークシステム |
| EP2274921B1 (en) * | 2008-04-22 | 2017-08-02 | Telefonaktiebolaget LM Ericsson (publ) | Signaling gateway for routing signaling messages |
| US9554307B2 (en) | 2012-05-07 | 2017-01-24 | Telefonaktiebolaget Lm Ericsson (Publ) | Communication apparatus and mobility method for mobile relay of backhaul links |
| CN104105086B (zh) * | 2013-04-11 | 2019-02-22 | 中兴通讯股份有限公司 | 临近业务服务器的选择方法及装置、用户注册方法及装置 |
| CN105900384A (zh) * | 2013-11-22 | 2016-08-24 | 日本电气株式会社 | 通信系统、中继设备、通信方法和用于存储程序的非瞬态计算机可读介质 |
| US20160323248A1 (en) * | 2013-12-31 | 2016-11-03 | Interdigital Patent Holdings Inc. | Methods, apparatus, systems and mechanisms for secure attribute based friend find and proximity discovery |
| EP3095212B1 (en) | 2014-01-14 | 2020-04-08 | Vodafone IP Licensing Limited | Group communication by relay |
| EP3146742B1 (en) | 2014-05-20 | 2019-07-31 | Nokia Technologies Oy | Exception handling in cellular authentication |
| US10079822B2 (en) * | 2014-06-30 | 2018-09-18 | Intel IP Corporation | Techniques for securely receiving critical communication content associated with a critical communication service |
| US10154475B2 (en) * | 2014-08-10 | 2018-12-11 | Lg Electronics Inc. | Method and device for selecting relay in wireless communication system |
| CN105828453A (zh) | 2015-01-04 | 2016-08-03 | 中兴通讯股份有限公司 | 中继通信的数据传输方法和装置 |
| US9992806B2 (en) | 2015-01-15 | 2018-06-05 | Intel IP Corporation | Public safety discovery and communication using a UE-to-UE relay |
| US9755837B2 (en) * | 2015-03-17 | 2017-09-05 | Qualcomm Incorporated | Apparatus and method for sponsored connectivity to wireless networks using application-specific network access credentials |
| US9723543B2 (en) | 2015-07-08 | 2017-08-01 | Blackberry Limited | Systems and methods for managing a UE-to-network relay |
| US10615844B2 (en) | 2016-03-15 | 2020-04-07 | Huawei Technologies Co., Ltd. | System and method for relaying data over a communication network |
| GB2548374A (en) | 2016-03-16 | 2017-09-20 | Nec Corp | Communication system |
| US10631224B2 (en) * | 2017-10-05 | 2020-04-21 | Blackberry Limited | Authenticating user equipments through relay user equipments |
-
2017
- 2017-10-05 US US15/725,563 patent/US10631224B2/en active Active
-
2018
- 2018-10-02 EP EP18864795.2A patent/EP3679655B1/en active Active
- 2018-10-02 ES ES18864795T patent/ES2971007T3/es active Active
- 2018-10-02 CN CN202211626533.1A patent/CN116033420B/zh active Active
- 2018-10-02 CN CN201880065335.8A patent/CN111183662B/zh active Active
- 2018-10-02 WO PCT/US2018/053913 patent/WO2019070668A1/en not_active Ceased
-
2020
- 2020-03-10 US US16/814,690 patent/US10993161B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CA3073091A1 (en) | 2019-04-11 |
| US20190110238A1 (en) | 2019-04-11 |
| EP3679655A1 (en) | 2020-07-15 |
| US10993161B2 (en) | 2021-04-27 |
| CN116033420A (zh) | 2023-04-28 |
| WO2019070668A1 (en) | 2019-04-11 |
| EP3679655A4 (en) | 2021-06-02 |
| EP3679655C0 (en) | 2024-02-14 |
| EP3679655B1 (en) | 2024-02-14 |
| CN116033420B (zh) | 2025-10-03 |
| CN111183662B (zh) | 2022-12-30 |
| US20200213927A1 (en) | 2020-07-02 |
| CN111183662A (zh) | 2020-05-19 |
| US10631224B2 (en) | 2020-04-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2971007T3 (es) | Autenticación de equipos de usuario a través de equipos de usuario de retransmisión | |
| JP7723782B2 (ja) | 異種アクセスネットワークを介した接続のセキュリティ実現のための方法及び装置 | |
| JP6823047B2 (ja) | セルラーアクセスネットワークノードのための識別子を含むネットワークアクセス識別子 | |
| CN109587688B (zh) | 系统间移动性中的安全性 | |
| ES2687453T3 (es) | Conectividad WLAN fiable a Núcleo de Paquetes Evolucionado 3GPP | |
| JP2022109996A (ja) | 認証要求を制御するためのプライバシインジケータ | |
| JP6628295B2 (ja) | 認証されていないユーザのための3gpp進化型パケットコアへのwlanアクセスを介した緊急サービスのサポート | |
| CN110249648B (zh) | 由未经认证的用户设备执行的用于会话建立的系统和方法 | |
| US9226153B2 (en) | Integrated IP tunnel and authentication protocol based on expanded proxy mobile IP | |
| WO2018184707A1 (en) | Provision of emergency codes to a mobile device | |
| ES2862180T3 (es) | Autenticación de usuarios en la red de acceso inalámbrico | |
| US20240187856A1 (en) | Registration authentication based on a capability | |
| CA3073091C (en) | Authenticating user equipments through relay user equipments | |
| US11283798B2 (en) | Network nodes and methods performed by network node for selecting authentication mechanism | |
| HK40022790B (en) | Authenticating user equipments through relay user equipments | |
| HK40022790A (en) | Authenticating user equipments through relay user equipments | |
| US20240305982A1 (en) | Secure authentication and identification in trusted non-3gpp access networks |