ES2949141T3 - Procedimiento de control de recursos de radio para la consulta de proveedores de servicios - Google Patents

Procedimiento de control de recursos de radio para la consulta de proveedores de servicios Download PDF

Info

Publication number
ES2949141T3
ES2949141T3 ES17720015T ES17720015T ES2949141T3 ES 2949141 T3 ES2949141 T3 ES 2949141T3 ES 17720015 T ES17720015 T ES 17720015T ES 17720015 T ES17720015 T ES 17720015T ES 2949141 T3 ES2949141 T3 ES 2949141T3
Authority
ES
Spain
Prior art keywords
query
user equipment
message
network
list
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES17720015T
Other languages
English (en)
Inventor
Mika Petri Olavi Rinne
Jari Pekka Mustajarvi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks Oy
Original Assignee
Nokia Solutions and Networks Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Solutions and Networks Oy filed Critical Nokia Solutions and Networks Oy
Application granted granted Critical
Publication of ES2949141T3 publication Critical patent/ES2949141T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/18—Selecting a network or a communication service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
    • H04W48/12—Access restriction or access information delivery, e.g. discovery data delivery using downlink control channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
    • H04W48/14—Access restriction or access information delivery, e.g. discovery data delivery using user query or user detection

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Telephone Function (AREA)

Abstract

Un equipo de usuario (UE) envía un mensaje de solicitud de consulta de control de recursos de radio (130) a una entidad de red sin tener que establecer primero una conexión RRC (160) y recibe un mensaje de respuesta de consulta (140) en respuesta a la solicitud de consulta de control de recursos de radio. mensaje (130). El UE selecciona un proveedor de servicios basándose en el mensaje de respuesta a la consulta. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Procedimiento de control de recursos de radio para la consulta de proveedores de servicios
Antecedentes
Campo
Varios sistemas de comunicación pueden beneficiarse de la conectividad de red mejorada a través de un proveedor de servicios disponible. Por ejemplo, ciertos sistemas de comunicación pueden beneficiarse de informar a un equipo de usuario de los proveedores de servicios disponibles sin tener que establecer primero una conexión de control de recursos de radio (RRC - Radio Resource Control).
Descripción de la técnica relacionada
En un sistema de extremo a extremo, una arquitectura de red puede incluir una red de acceso por radio (RAN - Radio Access Network), por ejemplo, una RAN MulteFire, que puede estar conectada a la red de núcleo de paquetes evolucionada (EPC - Evolved Packet Core) del Proyecto de Asociación de 3a Generación (3GPP) o a una red huésped neutra (NHN - Neutral Host Network). La red puede ser, por ejemplo, una red tradicional de evolución a largo plazo (LTE - Long Term Evolution) o una MulteFire Alliance. Una RAN conectada al EPC de 3GPP puede estar en modo de acceso de red móvil terrestre pública (PLMN - Public Land Mobile Network), mientras que una RAN conectada a la NHN puede estar en un modo de acceso NHN. Estos modos de acceso se definen en una MultiteFire Alliance (MFA), por ejemplo, y pueden ser adicionales, o diferentes de las últimas especificaciones del 3GPP. Otros foros, como el 3GPP, también pueden definir o redefinir estos mecanismos. La NHN puede soportar múltiples proveedores de servicios participantes (PSP - Participating Service Providers). Un equipo de usuario (EU) que accede a la NHN puede ser capaz de recuperar información parcial o abreviada sobre proveedores de servicios que ofrecen autenticación y conectividad a través de la red. Una red puede soportar múltiples PSP, de los cuales el EU puede seleccionar uno. La información de qué PSP son compatibles con la red puede afectar a la selección de red por parte del EU.
Debido a que la información sobre los PSP disponibles puede ser de uso al EU, la Información del Sistema (SI) de una celda dada puede necesitar incluir una lista de PSP. Los PSP son identificados por sus nombres que pueden ser nombres largos de tipo dominio. Sin embargo, los recursos de SI pueden ser escasos porque la SI puede necesitar transmitirse con una potencia de cobertura completa. Además, cuando se opera en una banda sin licencia o cualquier tipo de banda con licencia compartida o espectro de espacios en blanco, es posible que se necesite escuchar antes de hablar (LBT - Listen-Before-Talk) antes de cada ráfaga de transmisión de SI. Además, los elementos de información de una ráfaga de SI pueden necesitar estar disponibles periódicamente porque la red puede no estar consciente de cuándo el EU necesita alguna SI. Por lo tanto, es práctico que solo la forma corta de las ID de los PSP se difundan como parte de la SI o que solo se ofrezca una lista parcial de los PSP más utilizados, en lugar de una lista completa. La Solicitud de patente EP 2071 879 A1 describe un mecanismo de consulta para recuperar datos específicos de servicio asociados con uno o más proveedores de servicios de telecomunicaciones móviles.
Resumen
La invención se realiza en el procedimiento para enviar desde un equipo de usuario un mensaje de solicitud de consulta de control de recursos de radio a una entidad de red de una red central neutra según la reivindicación independiente 1. La invención también está incorporada en el dispositivo correspondiente de la reivindicación independiente 13. La invención se incorpora además en el procedimiento para recibir desde un equipo de usuario un mensaje de solicitud de consulta de control de recursos de radio en una entidad de red de una red huésped neutra según la reivindicación independiente 12 y al dispositivo relacionado de la reivindicación independiente 14. Finalmente, la invención se incorpora en el producto de programa informático de la reivindicación independiente 15.
Breve descripción de las figuras
Para un entendimiento apropiado de la invención, debería hacerse referencia a las figuras adjuntas, en donde: La Figura 1A ilustra un diagrama de flujo de señal según determinadas realizaciones.
La Figura 1B ilustra un diagrama de flujo de señal según determinadas realizaciones.
La Figura 2 ilustra un diagrama de flujo según determinadas realizaciones.
La Figura 3 ilustra un diagrama de flujo según determinadas realizaciones.
La Figura 4A ilustra una realización de un mensaje de Solicitud de Conexión de RRC.
La Figura 4B ilustra una realización de una Consulta de RRC según ciertas realizaciones.
La Figura 4C ilustra una realización de una Consulta de RRC según ciertas realizaciones.
La Figura 4D ilustra una realización de una Consulta de RRC según ciertas realizaciones.
La Figura 5 ilustra un diagrama de sistema según ciertas realizaciones.
Descripción detallada
La invención se define por las reivindicaciones independientes adjuntas, mientras que la siguiente descripción está destinada únicamente a fines ilustrativos. Ciertas realizaciones pueden proporcionar un mecanismo para que el EU recupere información de consulta, tal como información de PSP de forma larga de la red. El procedimiento de recuperación y selección puede ocurrir antes de establecer una conexión a la red. Ciertas realizaciones también pueden ser capaces de proporcionar tantos PSP disponibles en la red, teniendo cada PSP cualquier cantidad de longitud. Sin embargo, en algunas realizaciones, se puede proporcionar una longitud máxima, siendo la longitud máxima predeterminada o establecida por la red.
Además, ciertas realizaciones pueden operar en una red de evolución a largo plazo (LTE - Long Term Evolution) que opera en una banda de frecuencia sin licencia. En otros ejemplos, la banda de frecuencia puede ser una clase de espectro de espacios en blancos o banda con licencia compartida. En tal realización, el EU puede beneficiarse de ser informado de los proveedores de servicios disponibles. El EU puede recibir información de consulta solicitada, tal como una lista de proveedores de servicios completos con información de forma larga relacionada con los proveedores de servicios disponibles. Una vez recibidos, el EU puede seleccionar entonces un proveedor de servicios disponible para la conexión a la red. Diferentes redes pueden tener diferentes proveedores de servicios participantes.
En ciertas realizaciones, un EU puede no tener información suficiente sobre los proveedores de servicios participantes en una red. Por ejemplo, la SI puede no incluir los PSP o puede incluir solo una lista parcial de los PSP. En otro ejemplo más, la SI puede incluir solo identificaciones de PSP en forma corta, aunque el EU puede necesitar las identificaciones de los PSP en su forma larga. El EU también puede, por cualquier motivo, decidir no buscar listas de PSP a partir de la SI. En tales ejemplos, la SI no proporciona al EU una lista de PSP adecuada. Un procedimiento de consulta puede entonces ejecutarse por el EU cuando aún no tiene información suficiente sobre los PSP ofrecidos por una red.
Los procedimientos de consulta pueden incorporarse en un procedimiento de control de recursos de radio (RRC -Radio Resource Control). En otras realizaciones, el procedimiento de consulta puede incorporarse en otros procedimientos, por ejemplo, un estrato de no-acceso (NAS - Non-=Access Stratum). La consulta de RRC puede ocurrir en un estado en el que el EU selecciona una celda desde la que accede a una red. El EU puede enviar una entidad de red a una consulta sobre los PSP disponibles en la celda. La selección del proveedor de servicios puede determinarse por el EU basándose en al menos un criterio de selección.
El usuario del EU, o el EU, puede tener preferencias de selección de PSP preconfiguradas de modo que el EU en sí mismo pueda en ciertas realizaciones seleccionar automáticamente un PSP preferido. El EU también puede presentar la lista de PSP al usuario para selección manual. En algunas realizaciones, el EU puede presentar esos PSP para los cuales el EU tiene credenciales. Cada credencial está enlazada a un PSP, y el EU puede tener múltiples credenciales. Si se cumple al menos uno de los criterios de selección, y el EU decide acceder a la red, el EU puede entonces ejecutar el procedimiento de establecimiento de conexión de RRC. En algunas realizaciones, el procedimiento de establecimiento sucede después de completar el procedimiento de consulta de RRC y la selección del PSP. Por otro lado, si después de evaluar los PSP, el EU decide no acceder a una red, el EU puede elegir no establecer una conexión de RRC.
El EU puede optimizar el escaneo y puede detener el escaneo tan pronto como se haya detectado un PSP más preferido. El EU también puede recibir y almacenar PSP detectados, y su NHN de servicio. Si no se encuentra el PSP más preferido, el EU puede elegir los siguientes mejores PSP de los PSP detectados y seleccionar una NHN respectiva. El almacenamiento de los PSP detectados, y su servicio de NHN, puede ser selectivo. Por ejemplo, el EU puede elegir almacenar solo aquellos PSP, y NHN de servicio, para los cuales el EU tiene credenciales. Todas las demás NHN pueden marcarse como inutilizables y almacenarse en una lista separada o eliminarse.
El EU puede almacenar los PSP, y las NHN de servicio, durante cualquier cantidad de tiempo dada. En un ejemplo, puede haber un contador de PSP en la SI. El contador aumenta siempre que la información de PSP se actualice. El contador puede usarse para determinar la cantidad de tiempo en la que se almacenan los PSP y las NHN de servicio. El EU también puede decidir actualizar información de manera regular.
La Figura 1A ilustra un diagrama de flujo de señal según determinadas realizaciones. En particular, la Figura 1A puede ilustrar un ejemplo del procedimiento de consulta de RRC en LTE. Tras la selección de una celda por un EU, se puede enviar un primer mensaje (Msg1) desde el EU a una entidad de red en la capa física (PHY) como un procedimiento de acceso aleatorio, o como una parte del procedimiento de acceso aleatorio. En la etapa 110, se puede usar un canal de acceso aleatorio físico de LTE (PRACH - physical random access channel) para transportar preámbulos de acceso aleatorio desde el EU a la entidad de red para iniciar un procedimiento de acceso aleatorio.
En la etapa 120, una entidad de red puede detectar los preámbulos enviados a través del PRACH. La entidad de red puede ser un nodo de red o una estación base, tal como un Nodo B evolucionado (eNB). La entidad de red puede enviar entonces un segundo mensaje (Msg2) conocido como una respuesta de acceso aleatorio (RAR - Random Access Response) al EU como una unidad de datos de protocolo de control de acceso al medio (MAC PDU - media access control protocol data unit). La señalización de RAR puede ser identificada por un identificador temporal de red de radio de acceso aleatorio (RA-RNTI - Random Access Radio Network Temporary Identifier), que cualquier EU dado que haya transmitido un preámbulo de acceso aleatorio puede decidir recibir y decodificar. La entidad de red también puede asignar recursos iniciales dentro de RAR, para el uso de Portador de Radio de Señalización 0 (SRBO - Signaling Radio Bearer 0) al EU. Los recursos iniciales se pueden usar para la identificación de una solicitud de la consulta en un tercer mensaje (Msg3). Esta asignación inicial puede permitir que el EU use SRBO en el Canal de Control Común (CCCH - Common Control Channel) con el control de enlace de radio (RLC - Radio Link Control) en un modo transparente. Además, la entidad de red puede haber incluido en la RAR una identidad temporal de la red de radio celular temporal (C-RNTI - cell radio network temporary identity), que luego se usa para las siguientes asignaciones de recursos para el EU.
Como se describió anteriormente, la entidad de red puede asignar recursos iniciales, tales como SRBO, para la identificación del protocolo de consulta. En ciertas realizaciones en respuesta a la RAR, en lugar de enviar una solicitud de Conexión RRC en Msg3, el EU puede elegir enviar un mensaje de consulta de RRC como una solicitud de consulta a la entidad de red en la etapa 130. Ejemplos de cómo se puede variar el mensaje de solicitud de conexión de RRC para producir un mensaje de consulta de RRC se explican en las Figuras 4B, 4C y 4D. En ciertas realizaciones, una consulta es una variante del mensaje de solicitud de conexión de RRC, que identifica la consulta en lugar de la solicitud de conexión. Como tal, en ciertas realizaciones, el mensaje de consulta puede ser un mensaje de preasociación. El mensaje de preasociación puede significar que un EU se comunica con la red a través de una identidad de EU (EU-ID) aleatoria y, por lo tanto, se espera que la comunicación sea temporal y la conexión RRC aún no esté configurada o establecida. Este tipo de conexión temporal del EU y la red puede ser ligera, y puede no conducir al EU para entrar en un estado conectado de RRC o un estado de LTE conectado. El EU está en un estado de preasociación a la red de acceso puede permanecer invisible y desconocida para la red central.
La asociación previa también puede significar que el mensaje de consulta se está enviando para el EU antes de que se establezca la conexión RRC. Por ejemplo, un mensaje de preasociación puede ser un mensaje enviado antes de que se establezca cualquier conexión de RRC, o cuando un dispositivo esté en un estado de RRC no conectado. Alternativamente, la asociación previa puede significar que una asignación de recursos dedicada por una identidad de EU puede no ser necesaria para que se envíe la consulta, mientras que la asignación de recursos puede ocurrir por la C-RNTI temporal dado en la rAr . El SRBO es una asignación inicial o temporal, y puede no formar parte de la asignación de recursos dedicada por la entidad de red. En otra realización más, la asociación previa puede significar que se puede haber desconectado una conexión RRC anterior, y que la consulta puede enviarse antes de que se haya establecido una nueva conexión RRC. La asociación previa también puede significar que el EU envía el mensaje de solicitud de consulta antes de que el EU haya seleccionado un PSP. Además, la asociación previa puede significar que el EU es conocido por la red por su EU-ID aleatorio en lugar de su EU-ID real.
En ciertas realizaciones, el intercambio del mensaje de solicitud de consulta de control de recursos de radio y el mensaje de respuesta de consulta de control de recursos de radio puede significar que el EU puede estar asociado previamente a un elemento de red, o el EU puede estar en un estado de pre-asociación, o que el EU puede estar en estado de conexión de RRC ligero o un estado similar. En particular, el intercambio de mensajes de solicitud de consulta de control de recursos de radio y la respuesta de consulta de control de recursos de radio pueden significar que el EU puede no en el estado conectado de RRC con el elemento de red, al menos no completamente. Además, la asociación previa también puede significar que el EU puede no estar en un estado de LTE conectado con la red.
En el paso 130, el EU envía un mensaje de solicitud de consulta RRC a la entidad de red. El mensaje de solicitud de consulta RRC puede ser un mensaje de preasociación. En ciertas realizaciones, la consulta de r Rc incluirá un identificador de EU aleatorio (EU-ID). El EU-ID aleatorio puede usarse porque el EU-ID puede no ser conocido sin seleccionar primero los PSP de servicio. Esto se debe a que un EU-ID cae dentro del alcance de un proveedor de servicios, y el EU no sabrá qué EU-ID usar hasta que haya seleccionado un PSP. La entidad de red puede usar este EU-ID aleatorio recibido por el EU cuando responde a la consulta. Sin embargo, en alguna realización, el uso de EU-ID aleatorio en la respuesta de consulta no está presente.
El mensaje de solicitud de consulta puede incluir una solicitud de información que puede permitir que el EU seleccione un proveedor de servicios. Por ejemplo, la información puede tomar la forma de una lista de nombres de PSP de formato largo. Obtener dicha lista puede permitir que el EU seleccione un PSP a partir de la lista de PSP. El EU puede usar entonces el PSP seleccionado para autenticar y acceder a la red. En otras realizaciones, el EU puede solicitar que los PSP disponibles en una red se envíen en cualquier otra forma, que no se limita a una lista. Un EU puede intentar acceder y/o autenticar la red incorrectamente, lo que puede conducir a una falla de la autenticación y/o acceso a la red. Una consulta para información que permitirá al EU seleccionar un proveedor de servicios puede facilitar el acceso exitoso y la autenticación de una red, y evitar cualquier intento incorrecto para obtener acceso a la red.
En ciertas realizaciones, el mensaje de solicitud de consulta puede incluir una solicitud de un tipo de consulta. El tipo de consulta puede ser la forma en la que el EU desea recibir la información de PSP. Por ejemplo, el tipo de consulta puede ser una lista completa de PSP de formato largo. La entidad de red puede usar el tipo de consulta para formatear el mensaje de respuesta de consulta enviado al EU. Si el tipo de consulta es una lista PSP de formato largo completo, la entidad de red puede responder enviando una lista de PSP de formato largo completo al EU, como se muestra en la etapa 140.
Una lista de PSP puede, en ciertas realizaciones, incluir un nombre completo de un proveedor de servicios que toma la forma de caracteres de cadena psp_long_name. En otra realización, el nombre PSP puede dividirse en campos que forman el nombre, tal como, psptext 1, text2, o text3. Un nombre de PSP también puede incluir un nombre de dominio, por ejemplo, dominio psptext. En algunas de las realizaciones descritas anteriormente, el nombre de PSP puede representarse como psp_long_name, psptext1.text2.text3, o psptext@dominio.
En algunas realizaciones, la lista de PSP puede representarse como {Nb de lista de elementos Lista {longitud de elemento, nombre de PSP}. En otras realizaciones, la lista puede representarse como {Nb de lista de elementos Lista {longitud del elemento | nombre de PSP} primera lista / lista continua / última lista}. La lista de PSP puede tomar cualquier otra forma, y no se limita a los ejemplos anteriores.
Cuando el mensaje de solicitud de consulta es un mensaje de solicitud de consulta de RRC, el mensaje de respuesta de consulta también puede incluir el EU-ID aleatorio recibido por la entidad de red en la etapa 130. En una determinada realización de la invención, un mensaje de respuesta de consulta puede no incluir un EU-ID. Un mensaje de RRC puede incluir un identificador de transacción. En tal realización, el mensaje de respuesta de consulta de RRC puede incluir el mismo identificador de transacción para identificar que los mensajes son parte del mismo procedimiento. Además, puede incluirse un tipo de consulta.
El identificador de transacción puede unirse a un mensaje de respuesta de consulta a un mensaje de solicitud de consulta. Por lo tanto, el mensaje de solicitud de consulta y el mensaje de respuesta de consulta pueden incluir el identificador de transacción. El identificador de transacción puede cambiar en cada mensaje de solicitud de consulta o respuesta de consulta que se intercambia.
En algunas realizaciones, un identificador de transacción y/o un tipo de mensaje pueden no estar presentes en el mensaje. En otras realizaciones, la consulta puede identificarse como un campo de causa o como un conjunto de campos de causa para un mensaje de solicitud de consulta que puede estar presente en Msg3.
Como puede verse en la Figura 1, el mensaje de solicitud de consulta y el mensaje de respuesta de consulta pueden intercambiarse entre el EU y la entidad de red, y pueden enviarse como Msg3 y Msg4 de RRC, respectivamente. Debido a que la C-RNTI temporal ya está disponible para el EU, se puede usar la solicitud de repetición automática híbrida (HARQ - hybrid automatic repeat request). Usando HARQ se puede aumentar la fiabilidad de los mensajes de solicitud de consulta. Por ejemplo, en comparación con la difusión de SI sin HARQ, HARQ de Msg3 y MSg4 puede aumentar significativamente la fiabilidad del transporte de mensajes. HARQ proporciona además la adaptación a los formatos de enlace y calidad del enlace para una eficiencia mejorada del transporte de mensajes. Por ejemplo, HARQ puede usarse en una realización del procedimiento de acceso aleatorio en el que dos EU seleccionan la misma secuencia PRACH que se utilizará en el mismo recurso RACH. Seleccionar la misma secuencia PRACH puede crear una contención en Msg3 entre los EU. A pesar del conflicto, la entidad de red puede responder a al menos uno de los mensajes de solicitud de consulta del EU colocando el EU-ID aleatorio presente en Msg3 para resolver el conflicto.
En ciertas realizaciones, la entidad de red puede asignar recursos de enlace ascendente, usando la C-RNTI temporal para la Solicitud de Conexión RRC, después de que se haya completado la transmisión del mensaje de respuesta de consulta. Si el EU decide no establecer una conexión RRC, y no iniciar una Solicitud de Conexión RRC a una red dada, los residuos de recursos asignados pueden ser mínimos.
En algunas realizaciones, el mensaje de solicitud de consulta puede ser parte de un procedimiento NAS, en lugar del procedimiento RRC. La entrega de mensajes NAS, sin embargo, puede no ser posible, sin ejecutar primero una Solicitud de Conexión RRC o una Configuración de Conexión RRC en SRBO, y la ejecución de una Configuración de Conexión RRC completa en SRB1. Sin embargo, tener que ejecutar una Configuración de Conexión RRC puede ser oneroso porque puede conducir a establecer el contexto de EU completo en el nodo de red, además, ejecutar una Configuración de Conexión RRC puede incluir configurar las interfaces portador-EPS y plano de usuario (plano-U) a la red central. Por otro lado, usando el procedimiento de RRC y solo los recursos de SRBO para el protocolo de consulta pueden permitir una manipulación más ligera del contexto de EU en la entidad de red sin la necesidad de ninguna interacción de red central.
Por ejemplo, una operación de RRC más ligera puede incluir una o más de las siguientes relajaciones: un protocolo de control de enlace de radio operado en el modo transparente, un canal de control común que se usa, que se usa un tipo cero de portador de radio de señalización, un modo de seguridad no establecido, o un recurso de radio dedicado que no está configurado. Un recurso de radio dedicado que no está configurado, por ejemplo, puede no incluir configuración de movilidad, ningún objeto de medición y/o ningún informe de medición. Un ejemplo de recursos de radio que no están configurados puede incluir una falta de señales de referencia de programación de enlace ascendente y/o una falta de canales de control de enlace ascendente.
En la etapa 140 de la Figura 1, la entidad de red puede responder al mensaje de solicitud de consulta y enviar un mensaje de respuesta de consulta. El mensaje de respuesta de consulta también puede ser un mensaje de preasociación, y puede incluir, en ciertas realizaciones, una lista completa de nombres de PSP, por ejemplo, ID de PSP que tienen un formato largo. Cada ID de PSP individual en la lista PSP puede ser de longitud variable. También puede haber cualquier número de ID de PSP en una lista. En algunas realizaciones, la entidad de red puede decidir incluir solo un PSP único en un mensaje de respuesta de consulta. Esta decisión para incluir solo un PSP puede depender de diversos factores, incluyendo, por ejemplo, la longitud del PSP y la capacidad o cobertura, la entidad de red desea usar para el mensaje.
En otras realizaciones, la entidad de red puede decidir si enviar una lista de PSP en un único mensaje de respuesta de consulta, o si enviar múltiples mensajes de respuesta de consulta, cada uno incluye una lista de PSP. En ciertas realizaciones, un único mensaje de respuesta de consulta puede incluir una lista completa y completa de PSP que pueden no estar fragmentados. Como puede verse en la etapa 140 de la Figura 1, en algunas realizaciones la entidad de red puede elegir dividir la lista de PSP en múltiples mensajes de respuesta de consulta. Por ejemplo, en la etapa 140 se envían tres mensajes de respuesta de consulta desde la entidad de red al equipo de usuario. La entidad de red puede decidir dividir la lista de PSP en múltiples mensajes de respuesta de consulta, incluyendo cada uno una lista de PSP parcial, porque el RLC de SRBO puede no soportar segmentación cuando las PDU de RLC están en modo transparente.
Al enviar múltiples mensajes de respuesta de consulta, la información sobre si la lista parcial de PSP incluida en un mensaje de respuesta de consulta puede continuar con la siguiente lista de PSP recibida por el EU en el siguiente mensaje de respuesta de consulta puede codificarse en el formato de Notación de Sintaxis Abstracta Uno (asn.1) (Abstract Syntax Notation One) y colocarse en el mensaje. Información acerca de dónde finaliza un suministro de la lista de PSP, lo que significa que el mensaje de respuesta de consulta contiene el último conjunto de la lista de PSP, también puede incluirse en la asn.1. La notación asn.1 puede proporcionar una descripción autoexplicable del contenido de cada mensaje en forma de un único PSP o una lista de PSP. La notación asn. 1 también puede proporcionar información acerca de si el mensaje es una continuación o una finalización de una lista, y si esta indicación es condicional o opcional.
En ciertas realizaciones, la entidad de red puede decidir en qué orden de estructura y/o entregar uno o más PSP enumerados en la lista de PSP y/o en qué orden y cuántos de los PSP a estructura se entregan en cada uno de los uno o más mensajes de respuesta de consulta. Por ejemplo, la red puede priorizar diferentes PSP basándose en acuerdos mutuos. En algunas realizaciones, si la lista de PSP se divide en múltiples mensajes de respuesta de consulta, el EU puede no recibir los mensajes de respuesta de consulta en el mismo orden que la entidad de red transmitirlas, o haber previsto el EU para recibirlos. Cuando los mensajes de respuesta de consulta incluyen una descripción autoexplicativa del contenido en cada mensaje, el EU puede recibir los mensajes en cualquier orden sin confusión, y el EU puede decidir terminar la lectura de un mensaje de respuesta adicional en cualquier memento sin confusión.
Para evitar que la recepción potencial de la recepción de los PSP provoque confusión para el EU, el mensaje de respuesta de consulta puede incluir elementos de información de la lista PSP autodescodificables. Los elementos de información pueden usarse por el EU para poner juntos la lista PSP en el orden en el que se enviaron los mensajes de respuesta de consulta, o en el orden destinado a la entidad de red, o en cualquier orden proporcionado a través del enlace de transmisión. Además, el último mensaje de respuesta de consulta puede incluir una indicación de que este mensaje de respuesta de consulta particular es el último mensaje de respuesta de consulta. Después de recibir el último mensaje de respuesta de consulta, el mensaje de protocolo de consulta puede terminar en la etapa 150.
Una vez que el EU recibe la lista de PSP, el EU puede seleccionar un proveedor de servicios preferido de la lista de PSP. Si el EU recibe un proveedor de servicios preferido en una respuesta de consulta no completada aún, el EU aún puede seleccionar el proveedor de servicios e intentar el acceso, ya que las listas PSP pueden ser autoexplicativas y completas a través de la codificación en cualquier mensaje de respuesta de consulta. Alternativamente, después de recibir la respuesta de consulta completa, el EU puede decidir no seleccionar ninguna de las PSP soportadas por la red y elegir no conectarse a la red. El EU puede entonces decidir continuar buscando otras redes. El EU puede almacenar la lista de respuesta para uso futuro, vinculado a la NHN de la que se recibió la respuesta, como se discutió anteriormente. Si, por ejemplo, no se encontraron PSP más preferidos, el EU puede revisitar respuestas y elegir el mejor PSP y NHN disponibles. Además, en el caso de que se encontró PSP, el EU puede almacenar la relación de NHN y PSP encontrados. En algunas realizaciones, el EU puede mantener la lista de la más visitada, la más usada y/o el último número utilizado de NHN con los PSP EU utilizados en cada uno de ellos.
Como se discutió anteriormente, en ciertas realizaciones el mensaje de solicitud de consulta y los mensajes de respuesta de consulta se envían y reciben cuando el EU aún no está en el estado de conexión de RRC, permitiendo así que los mensajes sean mensajes de preasociación. Después de que finaliza el protocolo de consulta en 150, se puede realizar un procedimiento de RACH como se muestra en la Figura 1, y la entidad de red puede asignar recursos de Msg3 de enlace ascendente adicionales usando la C-RNTI temporal para identificar una oportunidad para que el EU realice una solicitud de conexión de RRC. La Solicitud de Conexión RRC puede entonces enviarse desde el EU a la entidad de red, como se muestra en la etapa 160. En algunas realizaciones, el PSP puede no ser visible hasta que el EU ejecute la autenticación con el NAS, punto en el cual la NHN, por ejemplo, la entidad de gestión de movilidad NHN, puede aprender la identidad del PSP seleccionado. La RAN, por otro lado, puede en ciertas realizaciones no aprender la identidad del PSP seleccionado. El EU puede saber que esta asignación es para la solicitud de conexión de RRC porque no hay necesidad de un recurso de enlace ascendente de este tipo, y también porque se anuncia la respuesta de consulta de RRC que ha terminado en el enlace descendente. En la etapa 170, la entidad de red puede enviar al EU una Configuración de Conexión RRC, incluyendo una configuración de recursos de radio. La Configuración de Recursos de Radio puede incluir configuraciones de recursos dedicados para la configuración de conexión completa.
En la etapa 180, el EU enviará un mensaje de Configuración de Conexión Finalizada RRC al nodo de red usando SRB1, en cuyo punto la conexión RRC puede establecerse completamente. El mensaje de Configuración de Conexión Finalizada RRC puede incluir una solicitud de servicio NAS integrada con identidades, de modo que puede establecerse el servicio de red central, y el EU puede realizar la transición al estado de LTE conectado. La Configuración de Conexión Finalizada RRC puede llevar un mensaje NAS que puede incluir la identificación del PSP seleccionado entre otros elementos de información. La identificación de PSP seleccionado puede ser directa o indirecta, siempre que la relación del PSP seleccionado a la PSP real pueda ser clara y única. Por ejemplo, el EU puede incluir en la solicitud de servicio NAS el número o código de PSP, si dicho número o código se entrega a lo largo de la lista PSP en el mensaje de respuesta de consulta. De otro modo, el EU puede adjuntar el nombre del PSP completo a la solicitud de servicio NAS.
La identidad del EU para la solicitud de servicio NAS se puede colocar en la solicitud de conexión RRC como una EU-ID real. En ciertas realizaciones, cuando el EU usa la C-RNTI temporal en la solicitud de conexión RRC, coloca la EU-ID real a los campos de la solicitud de servicio NAS junto con el nombre PSP. El EU, en ciertas realizaciones, puede incluir también un formato de un nombre de recurso uniforme agregando el nombre PSP o el nombre del dominio PSP con el nombre de identidad del EU.
En ciertas realizaciones, mientras que el EU y la entidad de red participan en el protocolo de consulta, la conexión RRC no se habría establecido. La entidad de red puede asignar una secuencia PRACH dedicada en la información de control de enlace descendente (DCI - downlink control information) para la conexión RRC derecha o después de que se envíe el mensaje de respuesta de consulta. El EU que usa la secuencia PRACH dedicada puede evitar usar el procedimiento RACH, y permite que la entidad de red asigne Msg3 para la Solicitud de Conexión RRC. Por ejemplo, los mensajes 110 y 120 no tendrán que repetirse nuevamente después del protocolo de consulta. Este preámbulo dedicado o secuencia PRACH puede tener un tiempo de validez especificado, que se define en un estándar y/o puede definirse en forma de ecuación de ventana de validez. La ecuación de ventana de validez puede incluir parámetros tales como instancias de recursos de transmisión, un número de instancias de recursos de transmisión o un valor de validez en tiempo real, por ejemplo, en unidades de milisegundos. La ecuación de ventana de validez también puede incluir factores que dependen del éxito de Escuchar Antes de Hablar de transmisión de un preámbulo. En una realización en la que el EU decide no intentar acceder a la red a través de la secuencia PRACH dedicada durante su ventana de tiempo de validez, la entidad de red puede no asignar recursos de Msg3, y puede eliminar todo el contexto para el EU bajo su EU-ID aleatoria almacenada, como se describió previamente. Cuando el EU no usa el recurso dedicado, la red puede tomar dicha falta de uso como un signo para eliminar el contexto del EU bajo la EU-ID aleatoria, y suponer que el EU está desconectado.
En algunas realizaciones, si el EU después de la expiración de la secuencia PRACH dedicada aún decide intentar acceder a la red, el EU puede ejecutar un procedimiento RACH con un preámbulo aleatorio, al tomar la decisión de acceder a la red, y enviar una Solicitud de Conexión RRC en el siguiente Msg3 asignado por la red en una RAR. Esto puede parecerse a una nueva solicitud de conexión RRC. Sin embargo, el EU puede tener ahora el conocimiento de los PSP ofrecidos obtenidos en la consulta anterior y, por lo tanto, el EU puede ejecutar la Solicitud de Conexión RRC, la configuración de la Conexión RRC y la Configuración de la Conexión RRC completa con su EU-ID real y con el PSP seleccionado, en oposición a la EU-ID aleatoria. En una realización, la EU-ID real y el PSP seleccionado se usan en el procedimiento NAS, y no pueden tener impacto en el procedimiento RRC, aunque se entrega en el mismo.
Como se explicó anteriormente, después de que termine el protocolo de consulta puede haber varias alternativas diferentes. En ciertas realizaciones, la red asigna recursos dedicados donde el EU puede colocar una Solicitud de Conexión RRC de Msg3. En otras realizaciones, la red puede asignar un preámbulo dedicado, que el EU puede usar en los recursos RACH. Tal realización puede ayudar a evitar el potencial. En aún otra realización, el EU puede ejecutar un procedimiento de acceso aleatorio con un preámbulo aleatorio después de la consulta, como se muestra en las etapas 360 y 370 de la Figura 3.
En otras realizaciones, el EU puede necesitar señalizar explícitamente su decisión no establecer una conexión RRC y dejar la celda. En algunas realizaciones, la entidad de red puede ejecutar un temporizador durante el cual se puede esperar que el EU señale la entidad de red de sus intenciones para establecer una conexión RRC. Si no se recibe dicha señal por la entidad de red antes de la expiración del temporizador, el contexto de EU bajo la EU-ID aleatoria se puede eliminar.
La Figura 1B ilustra un diagrama de flujo de señal según determinadas realizaciones. En la Figura 1B, después de los extremos de consulta en la etapa 150, la entidad de red puede asignar recursos dedicados. En ciertas realizaciones, la entidad de red puede asignar una secuencia PRACH dedicada en la información de control de enlace descendente (DCI) para la conexión RRC. El EU que usa la secuencia PRACH dedicada puede evitar usar el procedimiento RACH, y permite que la entidad de red asigne Msg3 para la Solicitud de Conexión RRC. En tales realizaciones, los mensajes 110 y 120 pueden no ser repetidos nuevamente después de los extremos de consulta en la etapa 150, y las etapas 360 y 370 de la Figura 3 pueden omitirse.
La Figura 2 ilustra un diagrama de flujo según determinadas realizaciones. En particular, la Figura 2 ilustra un mecanismo de consulta que usa un protocolo RRC. En la etapa 210, el EU busca una celda con la que establecer una conexión RRC. En ciertas realizaciones, el EU puede intentar conectarse a una red de base LTE que opera en una banda sin licencia. La red puede ser capaz de servir proveedores de servicios de operador de red no móviles (no MNO) (non-mobile network operator). En la etapa 220, el EU selecciona una celda adecuada basándose en criterios de selección de celda. Los criterios de selección de celdas, por ejemplo, pueden incluir uno o más umbrales de señal, umbrales de calidad de señal, umbrales de interferencia, umbrales de interferencia a interferencia, o cualquier combinación de los mismos. La clase de celda, las identidades de red y/o los códigos de restricción de acceso también se pueden usar como criterios para la evaluación de EU de la idoneidad de una celda dada. Los criterios de idoneidad celular pueden ser estandarizados, por ejemplo, según 3GPP.
El EU puede entonces recibir SI de la celda seleccionada, como se muestra en la etapa 230. En ciertas realizaciones, la SI puede incluir una lista parcial de identificaciones de PSP, o identificaciones de PSP de forma corta. SI las identificaciones de PSP proporcionadas en la SI son suficientes para que el EU seleccione un PSP, el EU puede moverse a la etapa 270 y decidir SI establecer una conexión RRC.
En ciertas realizaciones, sin embargo, la información PSP incluida en la SI puede no ser suficiente. En tal realización, el EU puede decidir enviar un mensaje de solicitud de consulta de control de recursos de radio, tal como un mensaje de solicitud de preasociación, a una entidad de red, como se muestra en la etapa 240. Alternativamente, el EU puede disponer dejar la red y no conectarse a la celda seleccionada. La solicitud de consulta, en ciertas realizaciones, puede incluir una solicitud de una lista de proveedores de servicios. Específicamente, el EU puede solicitar una lista completa de identificaciones de formato largo de los PSP. El EU también puede seleccionar una EU-ID aleatoria, y agregar la EU-ID aleatoria al mensaje de solicitud de consulta de preasociación.
En la etapa 250, el EU puede recibir un mensaje de respuesta de consulta en respuesta al mensaje de solicitud de consulta de control de recursos de radio enviado en la etapa 240. En ciertas realizaciones, el mensaje de respuesta de consulta puede incluir una lista completa de PSP. Como se muestra en la Figura 1, el mensaje de respuesta de consulta puede ser un único mensaje que contiene una lista completa de PSP, o más de un mensaje de respuesta de consulta, conteniendo cada mensaje un fragmento o una parte de la lista completa de PSP. El último mensaje de respuesta de consulta puede contener una indicación que informa al EU que es el último mensaje de respuesta de consulta. En ciertas realizaciones, el tamaño del mensaje de solicitud de consulta puede limitarse para evitar la segmentación de la solicitud. Además, el tamaño del mensaje de solicitud de consulta puede limitarse para adaptarse a los requisitos de Msg3 de RRC. Desde una perspectiva de gestión de recursos, el mensaje de solicitud de consulta puede ser similar, o en algunas realizaciones, idéntico al mensaje de Solicitud de Conexión RRC.
Tras la recepción del mensaje de respuesta de consulta, el EU puede seleccionar entonces un proveedor de servicios, como se muestra en la etapa 260. En realizaciones en las que el mensaje de respuesta de consulta incluye una lista de PSP, el EU puede seleccionar el proveedor de servicios de la lista de PSP. En ciertas realizaciones, después de evaluar la lista PSP, el EU puede determinar que la lista no contiene un proveedor de servicios preferido. El EU puede entonces decidir dejar sin establecer una conexión RRC. En aún otra realización, si el EU no selecciona un proveedor de servicios preferido, puede decidir y enviar posteriormente una solicitud de consulta de RRC adicional a la entidad de red.
En la etapa 270, por otro lado, el EU puede decidir establecer una conexión RRC, y enviar una Solicitud de Conexión RRC a la entidad de red. El EU puede incluir su EU-ID real para el proveedor de servicios seleccionado en el mensaje de solicitud de conexión de RRC y/o puede indicar además el PSP seleccionado en el mensaje de Configuración de Conexión Finalizada RRC. En una realización alternativa, donde el EU tiene C-RNTI, y genera una solicitud de Conexión RRC que incluye C-RNTI, el EU puede indicar la EU-ID real válida para un PSP, y el PSP seleccionado dentro de los elementos de información de solicitud de servicio NAS. En la etapa 280, la conexión RRC se establece como se describió anteriormente, y el EU puede acceder a la red NAS a través del proveedor de servicios seleccionado. Alternativamente, incluso después de seleccionar un proveedor de servicios, el EU puede dispositivo para dejar antes de establecer una conexión RRC.
La Figura 3 ilustra un diagrama de flujo según determinadas realizaciones. En particular, la Figura 3 ilustra un mecanismo de consulta que usa protocolo RRC. En la etapa 310, una entidad de red, por ejemplo, un eNB, puede detectar un PRACH usado para transportar preámbulos de acceso aleatorio desde el EU. En la etapa 320, la entidad de red puede responder al PRACH detectado enviando una respuesta de acceso aleatorio al EU. La respuesta de acceso aleatorio puede incluir una asignación de recursos iniciales, tales como SRBO, al EU para el mensaje de solicitud de consulta.
En ciertas realizaciones, la red puede recibir del EU un mensaje de solicitud de consulta de control de recursos de radio, como se muestra en la etapa 330, por ejemplo, un mensaje de solicitud de consulta de RRC preasociación. En ciertas realizaciones, el mensaje de solicitud de consulta puede incluir una solicitud de una lista de PSP. El mensaje de solicitud de consulta también puede incluir una EU-ID aleatoria, y puede incluir una solicitud de una lista completa de identificaciones de PSP de forma larga. En la etapa 340, la entidad de red puede crear y enviar al EU un mensaje de respuesta de consulta en respuesta al mensaje de solicitud de consulta de control de recursos de radio de asociación previa. El mensaje de respuesta de consulta puede incluir la lista solicitada de PSP. Como se muestra en la etapa 140 de la Figura 1, puede haber uno o más mensajes de respuesta de consulta. En algunas realizaciones, un único mensaje de respuesta de consulta puede incluir la lista completa de identificaciones de formato largo de PSP. En otras realizaciones, la lista completa puede dividirse en más de un mensaje de respuesta de consulta. El último mensaje de respuesta de consulta puede incluir una indicación que identifica el mensaje de respuesta de consulta como el último segmento, y libera recursos de SRBO para la sesión. Esta liberación de recursos de SRBO puede ser similar a la liberación de recursos en un rechazo de conexión de RRC.
Durante el envío del mensaje de respuesta de consulta, o cualquier tiempo antes o después del envío del mensaje de respuesta de consulta, la entidad de red puede señalizar al EU una asignación de secuencia de PRACH dedicada en la DCI, como se muestra en la etapa 350. Los recursos dedicados pueden usarse en los recursos PRACH después de que el EU reciba la respuesta de consulta. Si el EU determina que debería establecer una conexión RRC, la entidad de red puede volver a detectar un PRACH, en la etapa 360. En la etapa 370, la entidad de red puede enviar una RAR que asigna recursos para la solicitud de conexión de RRC en Msg3. El EU puede usar estos recursos asignados para enviar una Solicitud de Conexión RRC en la etapa 380. En la etapa 390, la entidad de red puede conectar el EU a la red a través de procedimientos de acceso a red.
En una realización alternativa, durante el envío del mensaje de respuesta de consulta, o en cualquier memento antes o después del envío del mensaje de respuesta de consulta, la red puede señalizar al EU una asignación de recurso dedicado, diferente de la secuencia de PRACH de preámbulo dedicada. Esta asignación de recursos dedicada puede ser un conjunto de unidades de recursos de bloque de recursos físicos (PRB - Physical Resource Block) asignadas una vez o repetidamente, por ejemplo, como un recurso semipersistente, para el uso de Msg3. Otro ejemplo de un recurso dedicado puede ser una señal de solicitud de programación que puede definirse en un recurso físico de control de enlace ascendente.
La Figura 4A ilustra una realización de un mensaje de Solicitud de Conexión de RRC. La Figura 4B, sin embargo, ilustra una realización de la consulta de RRC. Específicamente, la realización de la Figura 4B ilustra un ejemplo de cómo se puede modificar el mensaje de Solicitud de Conexión RRC para convertirse en el mensaje de solicitud de consulta de RRC, como se muestra en la etapa 130 de las Figuras 1A y 1B. Como se puede ver en la Figura 4B, el valor de causa restante de establecimiento puede establecerse igual a la consulta de PSP o una consulta.
La Figura 4C ilustra una realización de la consulta de RRC. Específicamente, la realización de la Figura 4C ilustra un ejemplo de cómo se puede modificar el mensaje de Solicitud de Conexión RRC para convertirse en el mensaje de solicitud de Consulta RRC. En ciertas realizaciones, el valor de reserva, fuera de la causa de establecimiento, que puede tener un tamaño de cadena de bits (1), puede asignarse para anunciar la consulta. Por ejemplo, en lugar de usar la causa de establecimiento de solicitud de conexión RRC heredada, el valor de reserva puede usarse para la solicitud de consulta. En otras palabras, la causa de la consulta se puede aplicar en lugar de la causa de Establecimiento, cuando se establece la consulta en 1.
En la realización de la Figura 4C, en la que la reserva se asigna a la consulta, un nuevo conjunto de valores de causa de establecimiento en un campo enumerado puede estar disponible para la consulta, como los valores de la causa de la consulta. La causa de la consulta puede tener ocho valores, si se establece igual al tamaño de la causa de establecimiento de mensaje heredado. Un valor de la causa de la consulta puede establecerse en la consulta de PSP. Otros valores pueden dejarse para otras consultas. Otros valores pueden incluir consultas en relación con una consulta de carga, una consulta de calidad o una consulta de nombre de servidor, por ejemplo.
La Figura 4D ilustra una realización de la consulta de RRC. Específicamente, la realización de la Figura 4D ilustra un ejemplo de cómo se puede modificar el mensaje de Solicitud de Conexión RRC para convertirse en el mensaje de solicitud de Consulta RRC. En ciertas realizaciones, todo el mensaje de Solicitud de Conexión RRC heredado puede ser rediseñado para la consulta. En ciertas realizaciones, el valor de reserva, fuera de la causa de establecimiento, puede tener un tamaño de cadena de bits igual a 1, y puede establecerse para anunciar la consulta. En una realización en la que el valor del bit se establece en una consulta, esto puede significar que el contenido de mensaje completo es diferente de la Solicitud de Conexión RRC. Además, en tal realización, la EU-ID aleatoria puede tener una longitud diferente, lo que puede permitir asignar bits para la descripción de subclases de consulta.
La Figura 5 ilustra un sistema según ciertas realizaciones. Debe entenderse que cada señal en las Figuras 1A y 1B, y cada bloque en las Figuras 2 y 3, pueden implementarse por varios medios o sus combinaciones, tales como hardware, software, firmware, uno o más procesadores y/o circuitos. En una realización, un sistema puede incluir varios dispositivos, tales como, por ejemplo, una entidad de red 520 o un EU 510. El sistema puede incluir más de un EU 510 y más de una entidad de red 520, aunque, a efectos ilustrativos, solo se muestra un nodo de acceso. Una entidad de red puede ser un nodo de red, una estación base, un eNB, un servidor, un host o cualquiera de los otros nodos de acceso o red descritos en esta invención.
Cada uno de estos dispositivos puede incluir al menos un procesador o unidad o módulo de control, indicados respectivamente como 511 y 521. En cada dispositivo puede proporcionarse al menos una memoria, indicadas como 512 y 522, respectivamente. La memoria puede incluir instrucciones de programa informático o código informático contenidos en la misma. Pueden proporcionarse unos transceptores 513 y 523, y cada dispositivo también puede incluir una antena, ilustradas respectivamente como 514 y 524. Aunque solo se muestra una antena, pueden proporcionarse muchas antenas y múltiples elementos de antena a cada uno de los dispositivos. Pueden proporcionarse otras configuraciones de estos dispositivos, por ejemplo. Por ejemplo, una entidad 520 de red y el EU 510 pueden configurarse adicionalmente para la comunicación por cable, además de para la comunicación inalámbrica, y en tal caso, las antenas 514 y 524 pueden ilustrar cualquier forma de hardware de comunicación, sin estar limitada simplemente a una antena.
Cada uno de los transceptores 513 y 523 puede ser, independientemente, un transmisor, un receptor o tanto un transmisor como un receptor, o una unidad o dispositivo que esté configurado tanto para la transmisión como para la recepción. El transmisor y/o el receptor (en lo que respecta a las partes de radio) también pueden implementarse como una unidad de entrada de radio remota que no está situada en el propio dispositivo, sino, por ejemplo, en un mástil. Las operaciones y funcionalidades pueden realizarse en distintas entidades, tales como nodos, hosts o servidores, de forma flexible. En otras palabras, la división del trabajo puede variar según el caso. Un posible uso es hacer que un nodo de red suministre contenido local. También pueden implementarse una o más funcionalidades como aplicaciones virtuales en software que pueden ejecutarse en un servidor.
Un dispositivo de usuario o equipo de usuario 510 puede ser una estación móvil (EM), tal como un teléfono móvil o un teléfono inteligente o un dispositivo multimedia, un ordenador, tal como una tableta, provisto de capacidad de comunicación inalámbrica, un asistente digital o personal de datos (PDA) provisto de capacidad de comunicación inalámbrica, un reproductor multimedia portátil, una cámara digital, una cámara de vídeo de bolsillo, una unidad de navegación provista de capacidad de comunicación inalámbrica o cualquier combinación de los mismos.
En alguna realización, un aparato, como un nodo de acceso, puede incluir medios para llevar a cabo las realizaciones descritas anteriormente en relación con las Figuras 1A, 1B, 2, 3, 4B, 4C y 4D. En determinadas realizaciones, puede configurarse al menos una memoria que incluye un código de programa informático para, con al menos un procesador, hacer que el aparato al menos realice cualquiera de los procedimiento descritos en la presente memoria.
Según determinadas realizaciones, un aparato 510 puede incluir al menos una memoria 512, que incluye un código de programa informático, y al menos un procesador 511. La al menos una memoria 512 y el código de programa informático están configurados, con el al menos un procesador 511, para hacer que el aparato 510 al menos envíe desde un equipo de usuario un mensaje de solicitud de consulta de control de recursos de radio a una entidad de red. La al menos una memoria 512 y el código de programa informático están configurados, con el al menos un procesador 511, para hacer que el aparato 510 al menos reciba en el equipo de usuario un mensaje de respuesta de consulta en respuesta al mensaje de solicitud de consulta de control de recursos de radio. Además, la al menos una memoria 512 y el código de programa informático están configurados, con el al menos un procesador 511, para hacer que el aparato 510 seleccione al menos en el equipo de usuario un proveedor de servicios basado en el mensaje de respuesta a la consulta.
Según determinadas realizaciones, un aparato 520 puede incluir al menos una memoria 522, que incluye un código de programa informático, y al menos un procesador 521. La al menos una memoria 522 y el código de programa informático están configurados, con al menos un procesador 521, para hacer que el aparato 520 al menos reciba desde un equipo de usuario un mensaje de solicitud de consulta de control de recursos de radio. La al menos una memoria 522 y el código de programa informático están configurados, con al menos un procesador 521, para hacer que el aparato 520 al menos envíe desde una entidad de red al equipo de usuario un mensaje de respuesta de consulta en respuesta al mensaje de solicitud de consulta de control de recursos de radio.
Los procesadores 511 y 521 pueden estar realizados por cualquier dispositivo informático o de procesamiento de datos, tal como una unidad central de procesamiento (CPU), un procesador de señales digitales (DSP), un circuito integrado específico de la aplicación (ASIC), dispositivos lógicos programables (PLD), matrices de puertas lógicas programables en campo (FPGA), circuitos mejorados digitalmente o un dispositivo comparable o una combinación de los mismos. Los procesadores pueden implementarse como un único controlador o como una pluralidad de controladores o procesadores.
En el caso de firmware o software, la implementación puede incluir módulos o una unidad de al menos un conjunto integrado auxiliar (p. ej., procedimientos, funciones, etc.). Las memorias 512 y 522 pueden ser, independientemente, cualquier dispositivo de almacenamiento adecuado, tal como un medio legible por ordenador no transitorio. Puede utilizarse una unidad de disco duro (HDD), una memoria de acceso aleatorio (RAM), una memoria flash u otra memoria adecuada. Las memorias pueden combinarse en un único circuito integrado como el procesador o pueden ser independientes del mismo. Además, las instrucciones de programa informático almacenadas en la memoria, y que pueden ser procesadas por los procesadores, pueden ser cualquier forma adecuada de código de programa informático, por ejemplo, un programa informático compilado o interpretado escrito en cualquier lenguaje de programación adecuado. La memoria o entidad de almacenamiento de datos es normalmente interna, pero también puede ser externa o una combinación de las mismas, tal como cuando se obtenga capacidad de memoria adicional de un proveedor de servicios. La memoria puede ser fija o extraíble.
La memoria y las instrucciones del programa informático pueden configurarse, con el procesador para el dispositivo en particular, para hacer que un aparato de hardware, como la entidad de red 520 o EU 510, realice cualquiera de los procesos descritos anteriormente (véanse, por ejemplo, las Figuras 1A, 1B, 2 y 3). Por lo tanto, en determinadas realizaciones, un medio no transitorio legible por ordenador puede codificarse con instrucciones informáticas o uno o más programas informáticos (tal como una rutina de software, applet o macro añadida o actualizada) que, cuando se ejecuten en hardware, pueden realizar un procedimiento tal como uno de los procedimientos descritos en la presente memoria. Los programas informáticos pueden codificarse mediante un lenguaje de programación, que puede ser un lenguaje de programación de alto nivel, tal como objective-C, C, C++, C#, Java, etc., o un lenguaje de programación de bajo nivel, tal como un lenguaje máquina o ensamblador. De forma alternativa, determinadas realizaciones de la invención pueden realizarse en su totalidad en hardware.
Además, aunque la Figura 5 ilustra un sistema que incluye una entidad de red 520 y un EU 510, determinadas realizaciones pueden ser aplicables a otras configuraciones, y a configuraciones que implican elementos adicionales, como se ilustra y analiza en la presente memoria. Por ejemplo, pueden estar presentes múltiples dispositivos de equipo de usuario y múltiples entidades de red, u otros nodos que proporcionen una funcionalidad similar, como nodos que combinan la funcionalidad de un equipo de usuario y una entidad de red, como un nodo de retransmisión. El EU 510 puede estar provisto igualmente de una variedad de configuraciones para la comunicación distintas de la entidad 520 de red de comunicación. Por ejemplo, el EU 510 puede estar configurado para la comunicación dispositivo a dispositivo.
Ciertas realizaciones permiten un mecanismo de consulta de preasociación usando protocolo RRC extendido. Se pueden incorporar dos nuevos mensajes de SRBO en un protocolo de RRC, incluyendo una solicitud de consulta de RRC y un mensaje de respuesta de consulta de RRC. El mecanismo de consulta puede usarse en todos los casos en los que el EU necesita recopilar información de la red antes de adjuntarse a la red, por ejemplo, una lista de proveedores de servicios. Además, el protocolo de consulta se puede someter antes o sin el establecimiento de una conexión RRC. El protocolo de consulta también puede ser compatible con una red LTE que opera en una banda sin licencia que es capaz de servir proveedores de servicios no MNO.
Los rasgos, estructuras o características de ejemplos de realización descritos a lo largo de esta memoria descriptiva pueden combinarse de cualquier manera adecuada en una o más realizaciones. Por ejemplo, el uso de las frases “ciertas realizaciones” , “algunas realizaciones” , “otras realizaciones” u otro lenguaje similar, a lo largo de esta especificación se refiere al hecho de que una característica, estructura o característica particular descrita en relación con la realización puede estar incluido en al menos una realización de la presente invención. Por lo tanto, la aparición de las frases “en ciertas realizaciones” , “en algunas realizaciones” , “en otras realizaciones” u otro lenguaje similar, a lo largo de esta especificación no se refiere necesariamente al mismo grupo de realizaciones, y las características, estructuras descritas, o las características pueden combinarse de cualquier manera adecuada en una o más realizaciones.
Un experto en la materia entenderá fácilmente que la invención como se ha analizado anteriormente puede ponerse en práctica con etapas en un orden diferente, y/o con elementos de hardware en configuraciones que son diferentes de las que se divulgan. Por lo tanto, aunque la invención se ha descrito basándose en estas realizaciones preferidas, a los expertos en la técnica les resultará evidente que son evidentes determinadas modificaciones, variaciones y construcciones alternativas aun permaneciendo dentro del alcance de la invención.
Glosario parcial
LBT Escuchar antes de hablar
LTE Tecnología de evolución a largo plazo de 3GPP
MAC Control de acceso al medio
EU Equipo de usuario
RRC Control de recursos de radio
eNB Nodo B evolucionado
PDU Unidad de datos de protocolo
pRACH canal físico de acceso aleatorio
PSP Proveedor de Servicios Participante
RAR Respuesta de Acceso Aleatorio
SI Información del Sistema
SRB Portadora de radio de señales
RLC Control de enlace de radio
PDU Unidad de datos de protocolo
RAN Red de acceso por radio
LBT Escuchar antes de hablar
LTE Tecnología de evolución a largo plazo de 3GPP
MAC Control de acceso al medio
EU Equipo de usuario
RRC Control de recursos de radio
eNB Nodo B evolucionado
PDU Unidad de datos de protocolo
pRACH Canal físico de acceso aleatorio
PSP Proveedor de Servicios Participante
RAR Respuesta de Acceso Aleatorio
SI Información del Sistema
SRB Portadora de radio de señales
RLC Control de enlace de radio
PDU Unidad de datos de protocolo
RAN Red de acceso por radio

Claims (15)

REIVINDICACIONES
1. Un procedimiento que comprende:
enviar (130) desde un equipo de usuario un mensaje de solicitud de consulta de control de recursos de radio a una entidad de red de una red de servidor neutra;
recibir (140) en el equipo de usuario un mensaje de respuesta de consulta que incluye una lista de proveedores de servicios en respuesta al mensaje de solicitud de consulta de control de recursos de radio;
en donde la señalización de recursos de portador de radio del portador de radio de señalización 0 se usa para el mensaje de solicitud de consulta y el mensaje de respuesta de consulta; seleccionar en el equipo de usuario un proveedor de servicios basándose en el mensaje de respuesta de consulta; y
enviar (160) desde el equipo de usuario a la red central neutra una solicitud de control de recursos de radio que incluye una identidad temporal de red de radio celular e indicando una identificación de equipo de usuario para el proveedor de servicios seleccionado en un elemento de información de solicitud de servicio de estrato de no acceso.
2. El procedimiento según la reivindicación 1, en donde el mensaje de solicitud de consulta incluye una solicitud de una lista de proveedores de servicios.
3. El procedimiento según una cualquiera de las reivindicaciones 1 a 2, en donde el equipo de usuario selecciona un proveedor de servicios de la lista de proveedores de servicios.
4. El procedimiento según la reivindicación 2, en donde la lista de proveedores de servicios incluye una lista completa de identificaciones de forma larga de los proveedores de servicios.
5. El procedimiento según una cualquiera de las reivindicaciones 1 a 4, que comprende, además:
seleccionar una identificación de equipo de usuario aleatorio; y
añadir el identificador de equipo de usuario aleatorio al mensaje de solicitud de consulta.
6. El procedimiento según una cualquiera de las reivindicaciones 1 a 5, en donde el mensaje de solicitud de consulta de control de recursos de radio es un mensaje de solicitud de preasociación, y en donde el mensaje de solicitud de preasociación no requiere asignación de recursos dedicados.
7. El procedimiento según una cualquiera de las reivindicaciones 1 a 6, que comprende, además: iniciar procedimientos de acceso aleatorio para tener un recurso de portador de radio de señalización asignado para su uso en el envío del mensaje de solicitud de consulta.
8. El procedimiento según una cualquiera de las reivindicaciones 1 a 7, que comprende, además:
recibir información del sistema en el equipo de usuario, en donde la información del sistema no contiene suficiente información relacionada con los proveedores de servicios.
9. El procedimiento según la reivindicación 2, que comprende, además:
recibir al menos un mensaje de respuesta de consulta adicional, que incluye la lista restante de los proveedores de servicios, cuando el mensaje de respuesta de consulta no incluyó una lista completa de los proveedores de servicios.
10. El procedimiento según una cualquiera de las reivindicaciones 1 a 9, en donde el equipo de usuario opera en una banda sin licencia.
11. El procedimiento según una cualquiera de las reivindicaciones 1 a 10, que comprende, además:
recibir una asignación de recursos dedicados, aparte de la secuencia de canal de acceso aleatorio físico de preámbulo dedicada; y
enviar un mensaje de control de recursos de radio a la entidad de red utilizando los recursos dedicados después de la selección del proveedor de servicios.
12. Un procedimiento que comprende:
recibir (130) desde un equipo de usuario un mensaje de solicitud de consulta de control de recursos de radio en una entidad de red de una red de servidor neutra;
enviar (140) a partir de la entidad de red al equipo de usuario un mensaje de respuesta de consulta que incluye una lista de proveedores de servicios en respuesta al mensaje de solicitud de consulta de control de recursos de radio;
en donde la señalización de recursos de portador de radio del portador de radio de señalización 0 se usa para el mensaje de solicitud de consulta y el mensaje de respuesta de consulta; y recibir (160) desde el equipo de usuario en la entidad de red una solicitud de control de recursos de radio que incluye una identidad temporal de red de radio celular e indicando una identificación de equipo de usuario para el proveedor de servicios seleccionado en un elemento de información de solicitud de servicio de estrato de no acceso.
13. Un aparato (510) que comprende:
al menos una memoria (512) que incluye código de programa informático;
al menos un procesador (511);
en donde la al menos una memoria (512) y el código de programa informático están configurados para, con el al menos un procesador (511), hacer que el aparato (510) al menos: envíe, desde un equipo de usuario, un mensaje de solicitud de consulta de control de recursos de radio a una entidad de red de una red de servidor neutra;
reciba, en el equipo de usuario, un mensaje de respuesta de consulta que incluya una lista de proveedores de servicios en respuesta al mensaje de solicitud de consulta de control de recursos de radio;
en donde la señalización de recursos de portador de radio del portador de radio de señalización 0 se usa para el mensaje de solicitud de consulta y el mensaje de respuesta de consulta; seleccione, en el equipo de usuario, un proveedor de servicios basándose en el mensaje de respuesta de consulta; y
envíe, desde el equipo de usuario a la red central neutra, una solicitud de control de recursos de radio que incluya una identidad temporal de red de radio celular e indicando una identificación de equipo de usuario para el proveedor de servicios seleccionado en un elemento de información de solicitud de servicio de estrato de no acceso.
14. Un aparato (520) que comprende:
al menos una memoria 522 que incluye código de programa informático;
al menos un procesador (521);
en donde la al menos una memoria (522) y el código de programa informático están configurados para, con el al menos un procesador (521), hacer que el aparato (520) al menos:
reciba, desde un equipo de usuario, un mensaje de solicitud de consulta de control de recursos de radio en una entidad de red de una red de servidor neutra; y
envíe, desde la entidad de red al equipo de usuario, un mensaje de respuesta de consulta que incluye una lista de proveedores de servicios en respuesta al mensaje de solicitud de consulta de control de recursos de radio;
en donde la señalización de recursos de portador de radio del portador de radio de señalización 0 se usa para el mensaje de solicitud de consulta y el mensaje de respuesta de consulta; y
reciba, desde el equipo de usuario en la entidad de red, una solicitud de control de recursos de radio que incluya una identidad temporal de red de radio celular e indicando una identificación de equipo de usuario para el proveedor de servicios seleccionado en un elemento de información de solicitud de servicio de estrato de no acceso.
15. Un producto de programa informático para un ordenador, que comprende porciones de código de software para realizar las etapas de cualquiera de las reivindicaciones 1 a 12 cuando dicho producto se ejecuta en el ordenador.
ES17720015T 2016-04-20 2017-04-11 Procedimiento de control de recursos de radio para la consulta de proveedores de servicios Active ES2949141T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/134,042 US20170311243A1 (en) 2016-04-20 2016-04-20 Radio resource control procedure for query of service providers
PCT/EP2017/058632 WO2017182324A1 (en) 2016-04-20 2017-04-11 Radio resource control procedure for query of service providers

Publications (1)

Publication Number Publication Date
ES2949141T3 true ES2949141T3 (es) 2023-09-25

Family

ID=58640824

Family Applications (1)

Application Number Title Priority Date Filing Date
ES17720015T Active ES2949141T3 (es) 2016-04-20 2017-04-11 Procedimiento de control de recursos de radio para la consulta de proveedores de servicios

Country Status (5)

Country Link
US (1) US20170311243A1 (es)
EP (1) EP3446520B1 (es)
CN (1) CN109196919B (es)
ES (1) ES2949141T3 (es)
WO (1) WO2017182324A1 (es)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107135530B (zh) * 2016-02-26 2020-10-02 北京佰才邦技术有限公司 提供服务提供商标识的方法、装置、接入设备及终端设备
CN105939522B (zh) * 2016-04-15 2019-07-09 北京佰才邦技术有限公司 发送服务提供商标识的方法、设备和系统
US10149344B2 (en) * 2016-05-09 2018-12-04 Htc Corporation Device and method of handling a radio resource control state change
US10880748B1 (en) * 2019-11-06 2020-12-29 Cisco Technology, Inc. Open access in neutral host network environments
CN113950109B (zh) * 2020-07-16 2024-03-05 中国电信股份有限公司 网络服务方法、装置、系统和存储介质
EP4156740B1 (en) * 2020-08-28 2024-05-01 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Method for wireless communication and network device
EP4229995A1 (en) * 2020-10-15 2023-08-23 Telefonaktiebolaget LM Ericsson (publ) Handling the unknown rrc establishment cause value in nr

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2346507B (en) * 1999-01-30 2003-08-27 Motorola Ltd Selecting a network in a cellular communications system
RU2316149C2 (ru) * 2004-12-07 2008-01-27 Самсунг Электроникс Ко., Лтд. Способ, устройство информирования абонентским оборудованием сети радиосвязи о выбранной базовой сети в системах с совместным использованием сетевых ресурсов
CN101272336B (zh) * 2007-03-21 2015-03-25 创新音速有限公司 无线通信系统处理随机访问过程的方法及其相关装置
EP2071879B1 (en) * 2007-12-13 2012-08-29 Alcatel Lucent Method of providing a terminal with a telecommunication service
KR101609580B1 (ko) * 2010-02-10 2016-04-07 삼성전자주식회사 무선 통신 시스템 및 그의 사용자 단말기와 이동성 관리 엔티티 간 연결 방법
US20120250601A1 (en) * 2011-03-28 2012-10-04 Hyung-Nam Choi Communication terminal, method for exchanging data, communication device and method for establishing a communication connection
US9591544B2 (en) * 2012-11-12 2017-03-07 Lg Electronics Inc. Method for reselecting cell in wireless communication system and apparatus supporting same
CN104247470B (zh) * 2013-04-09 2020-06-02 华为技术有限公司 数据传输方法、装置及系统
US9332480B2 (en) * 2014-03-28 2016-05-03 Qualcomm Incorporated Decoupling service and network provider identification in wireless communications
CN103945320B (zh) * 2014-04-08 2017-10-17 上海华为技术有限公司 无线网络控制器、通过寻呼触发终端接入的方法及系统
US10285114B2 (en) * 2015-07-29 2019-05-07 Qualcomm Incorporated Techniques for broadcasting service discovery information
EP3391689A1 (en) * 2015-12-18 2018-10-24 Nokia Solutions and Networks Oy Method, apparatus and computer program product for accessing a local area scoped network having non-access-stratum procedures

Also Published As

Publication number Publication date
EP3446520B1 (en) 2023-06-07
EP3446520A1 (en) 2019-02-27
WO2017182324A1 (en) 2017-10-26
CN109196919B (zh) 2021-10-12
CN109196919A (zh) 2019-01-11
US20170311243A1 (en) 2017-10-26

Similar Documents

Publication Publication Date Title
ES2949141T3 (es) Procedimiento de control de recursos de radio para la consulta de proveedores de servicios
US20220369215A1 (en) Relay selection in cellular sliced networks
JP6563518B2 (ja) カバレージ拡張された低複雑度マシン・タイプ通信のためのランダム・アクセス応答位置インジケータ
JP7501542B2 (ja) Ｕｅ、およびｕｅの方法
US10834593B2 (en) Method, apparatus and computer program product for accessing a local area scoped network having non-access-stratum procedures
ES2716014T3 (es) Sistemas y procedimientos para una rápida configuración inicial de enlace de red
ES2714287T3 (es) Sistemas y procedimientos para una rápida configuración inicial de enlace de red
ES2663854T3 (es) Dispositivo y procedimientos de comunicaciones
ES2523891T3 (es) Temporizador de espera de mensaje de liberación de conexión de control de recursos radio
US9380614B2 (en) Method of performing communication by user equipment in cloud radio access network environment and apparatus therefor
CN106162513B (zh) 支持优先级的接近业务直接通信的方法和装置
ES2936010T3 (es) Comunicaciones de descubrimiento de red móvil terrestre pública (“PLMN”) en una red inalámbrica
ES2929321T3 (es) Método de transmisión de datos y dispositivo terminal
CN108289335B (zh) 数据发送方法及装置、终端
EP3761751A1 (en) Relay selection in cellular sliced networks
US20210168743A1 (en) Base Station Coordinated Synchronization Block Transmissions in Integrated Access and Backhaul Network
ES2908398T3 (es) Métodos y sistema de transmisión de un identificador temporal
CN109644503B (zh) 用于随机接入的方法、网络设备和终端设备
JP2018522501A (ja) 単一の接続性コンテキストを用いた複数の同時のサービスコンテキストのサポート
EP3849103A1 (en) Relay selection in cellular sliced networks
EP3005806B1 (en) Telecommunications apparatus and method relating to a random access procedure
ES2828252T3 (es) Mejora o habilitación de la cobertura por radio para un equipo de usuario con respecto a una red de comunicación móvil
ES2837141T3 (es) Unidad de comunicación empleada como enrutador remoto y método de aplicación
JP2019503613A (ja) アップリンクブロードキャストの方法、端末デバイス及びネットワークノード
US9392629B2 (en) Method for setting synchronization between device-to-device communication terminals based on cellular communication system