ES2794566T3 - Terminal y procedimiento de comunicación del mismo - Google Patents

Terminal y procedimiento de comunicación del mismo Download PDF

Info

Publication number
ES2794566T3
ES2794566T3 ES16835400T ES16835400T ES2794566T3 ES 2794566 T3 ES2794566 T3 ES 2794566T3 ES 16835400 T ES16835400 T ES 16835400T ES 16835400 T ES16835400 T ES 16835400T ES 2794566 T3 ES2794566 T3 ES 2794566T3
Authority
ES
Spain
Prior art keywords
terminal
prose
tmgi
mbms
relay
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
ES16835400T
Other languages
English (en)
Inventor
Youngkyo Baek
Sunghoon Kim
Hoyeon Lee
Sung Hwan Won
Songyean Cho
Erik Guttman
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.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
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 Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Application granted granted Critical
Publication of ES2794566T3 publication Critical patent/ES2794566T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/023—Services making use of location information using mutual or relative location information between multiple location based services [LBS] targets or of distance thresholds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0215—Traffic management, e.g. flow control or congestion control based on user or device properties, e.g. MTC-capable devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0205—Traffic management, e.g. flow control or congestion control at the air interface
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/60—Subscription-based services using application servers or record carriers, e.g. SIM application toolkits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria
    • H04W72/566—Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient
    • H04W72/569—Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient of the traffic information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/14—Direct-mode setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/40—Connection management for selective distribution or broadcast
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/18—Interfaces between hierarchically similar devices between terminal devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/005—Discovery of network devices, e.g. terminals

Landscapes

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

Abstract

Un procedimiento por un terminal (1510) remoto de soporte de un servicio en un sistema (1590) de comunicación inalámbrica, comprendiendo el procedimiento: transmitir (1710), a un terminal (1520) de retransmisión, un mensaje de petición de supervisión de identificador de grupo móvil temporal, TMGI, que comprende un TGMI y prioridad por paquete de servicio basado en proximidad, ProSe, asociada con el TMGI; recibir (1720), desde el terminal (1520) de retransmisión, un mensaje de respuesta de supervisión de TMGI que comprende un identificador de grupo de capa 2 de ProSe para la identificación de un grupo para la recepción de un tráfico de servicio de multidifusión de difusión multimedia, MBMS, que corresponde al TMGI; y recibir (1740), desde el terminal (1520) de retransmisión, el tráfico de MBMS asociado con el identificador de grupo de capa 2 de ProSe, en el que el tráfico de MBMS se transmite por el terminal de retransmisión a base de la prioridad por paquete de ProSe, en el que el mensaje de petición de supervisión de TMGI comprende además identidades de área de servicio, SAI, de MBMS.

Description

DESCRIPCIÓN
Terminal y procedimiento de comunicación del mismo
Campo técnico
La presente invención se refiere a dos procedimientos interrelacionados y dos terminales correspondientes.
Antecedentes de la técnica
En general, un sistema de comunicación móvil se ha desarrollado para proporcionar comunicación mientras asegura la movilidad de un usuario. El sistema de comunicación móvil puede proporcionar un servicio de comunicación por voz y un servicio de comunicación de datos a alta velocidad mediante el progreso rápido de tecnologías.
En años recientes, como uno de los sistemas de comunicación móvil de siguiente generación, está en progreso la normalización para un sistema de Evolución a Largo Plazo (LTE) en el Proyecto Común de Tecnologías Inalámbricas de la 3a Generación (3GPP). El sistema de LTE se ha desarrollado para comercializarse en 2010 y es una tecnología de implementación de comunicaciones basadas en paquetes a alta velocidad teniendo una tasa de transmisión de hasta 100 Mbps mayor que una tasa de transmisión de datos que se proporciona actualmente y la normalización del sistema de LTE está casi terminada en la actualidad.
Mientras tanto, la Internet ha evolucionado a una red de Internet de las Cosas (loT) que transmite y recibe información, tal como cosas, entre componentes distribuidos y procesa la información, en una red de conexión centrada en el hombre en la que el hombre genera y consume información. También ha surgido la tecnología de Internet de todo (loE) en la que la tecnología de procesamiento de grandes volúmenes de datos, etc., mediante conexión con un servidor en la nube, etc., se combina con la tecnología de IoT. Para implementar la IoT, se han requerido elementos de tecnología, tales como una tecnología de detección, una infraestructura de red de comunicación por cable e inalámbrica, una tecnología de interfaz de servicio y una tecnología de seguridad. En la actualidad, se han investigado tecnologías, tales como una red de sensores de conexión entre cosas, Máquina a Máquina (M2M) y comunicación entre máquinas (MTC).
En el entorno de IoT, puede proporcionarse un servicio de tecnología de Internet (IT) inteligente que crea un nuevo valor en la vida humana recopilando y analizando datos generados en las cosas conectadas. La IoT puede aplicarse a campos, tales como una casa inteligente, un edificio inteligente, una ciudad inteligente, un coche inteligente o un coche conectado, una red inteligente, una atención médica, electrodomésticos inteligentes y un servicio de atención médica avanzada fusionando y combinando la tecnología de la información (IT) existente con diversas industrias.
La tecnología de IoT ha estado en el foco en diversos campos y operadores y vendedores han desarrollado varias aplicaciones y sistemas usando la IoT. Entre diversas soluciones de IoT, en particular, ha estado en el foco una IoT celular (en lo sucesivo, 'CIoT') usando una banda de frecuencia autorizada asignada al sistema celular. El sistema celular puede proporcionar una comunicación relativamente más fiable que un sistema no celular, proporcionando de este modo el servicio fiable. En conexión con la CIoT, las actividades de normalización de comunicación entre máquinas evolucionada (eMTC), CIoT de red de acceso de radio de evolución de la tasa de datos mejorada para GSM (GERAN) de Sistema Global para Comunicaciones Móviles, etc., han progresado activamente y en características de las actividades de normalización, una necesidad de operadores a menudo tiene un efecto crucial en una determinación de la norma.
La tecnología de comunicación evolucionada puede proporcionar comunicaciones entre todas las cosas así como entre usuarios, que se expresa por la expresión "Internet de las Cosas (IoT)". Por ejemplo, un usuario puede tener diversas clases de dispositivos electrónicos. Todos los dispositivos electrónicos se conectan entre sí mediante una tecnología de comunicación móvil o comunicación de área, diversos sensores, etc., de tal forma que es posible proporcionar funciones más convenientes al usuario o realizar un control eficiente entre los dispositivos. Los dispositivos electrónicos pueden llamarse colectivamente un dispositivo de IoT. Un ejemplo de otro servicio de IoT puede incluir equipo de medición que mide consumo de electricidad y agua de un edificio y que transfiere los valores medidos a través de una red. Como otro ejemplo, los aparatos de IoT de determinación de situaciones de seguridad pueden instalarse en lugares públicos o áreas remotas para seguridad pública. Cuando se producen eventos específicos, los aparatos de IoT pueden notificar las situaciones de evento a través de una red. Como otro ejemplo, electrodomésticos en una casa incluyen una función de conexión de red y, por lo tanto, puede realizarse una operación de desencadenamiento de dispositivo de notificar un estado de los electrodomésticos o de permitir que un usuario emita un comando a los electrodomésticos para que realicen una operación específica.
El dispositivo de IoT incluye módulos de comunicación móvil tales como Evolución a Largo Plazo (LTE) o módulos de comunicación de área local tales como Bluetooth, LAN inalámbrica (WiFi), Zigbee y comunicación de campo cercano (NFC).
El terminal de LTE también puede operarse en una frecuencia de portadora de LTE y también puede operarse en una banda de ISM. El documento "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on extended architecture support for proximity-based services (Release 13)" 3GPP TR 23.713 V1.5.0 estudia y evalúa posibles mejoras de arquitectura para un sistema de servicios basados en proximidad.
Divulgación de la invención!
La invención se define en las reivindicaciones.
Realizaciones ilustrativas se describen a continuación para ilustrar la invención.
Breve descripción de los dibujos
La Figura 1 es un diagrama que ilustra un ejemplo de un procedimiento de registro de un terminal en una red de operador móvil y un servidor de aplicación, de acuerdo con una realización de la presente invención.
La Figura 2 es un diagrama que ilustra una realización de una interfaz de Rx de acuerdo con una realización de la presente invención.
La Figura 3 es un diagrama que ilustra un ejemplo de un procedimiento de transferencia de señalización relacionada con difusión de acuerdo con una realización de la presente invención.
La Figura 4 es un diagrama que ilustra un procedimiento de establecimiento de SI entre una estación base y una MME de acuerdo con una realización de la presente invención.
La Figura 5 es un diagrama que ilustra un procedimiento de actualización de configuración de eNB entre la estación base y la MME de acuerdo con una realización de la presente invención.
La Figura 6 es un diagrama que ilustra un procedimiento de establecimiento de M3 entre una MCE y la MME de acuerdo con una realización de la presente invención.
La Figura 7 es un diagrama que ilustra un procedimiento de actualización de configuración de MCE entre la MCE y la MME de acuerdo con una realización de la presente invención.
La Figura 8 es un diagrama que ilustra un ejemplo de una estructura de red que soporta un servicio de CIoT de acuerdo con una realización de la presente invención.
La Figura 9 es un diagrama que ilustra otro ejemplo de la estructura de red que soporta un servicio de CIoT de acuerdo con una realización de la presente invención.
La Figura 10 es un diagrama que ilustra un procedimiento de permitir que un nodo de CN de CIoT adquiera información de suscripción que incluye un tipo que divide tráfico de datos de acuerdo con fin o características del terminal de CIoT desde HSS cuando un terminal de CIoT realiza una petición de servicio/actualización de área de seguimiento/conexión, de acuerdo con una realización de la presente invención.
La Figura 11 es un diagrama que ilustra un procedimiento de permitir que un terminal de CIoT transmita un tipo de acuerdo con un modelo de tráfico o el fin / características del terminal de CIoT cuando el terminal de CIoT realiza la petición de servicio/actualización de área de seguimiento/conexión, de acuerdo con una realización de la presente invención.
Las Figuras 12 a 14 son diagramas que ilustran un procedimiento y un procedimiento de aplicación de prioridad cuando el terminal de CIoT y una red de CIoT realizan radiobúsqueda y cuando el terminal de CIoT y la red de CIoT transfieren un paquete, de acuerdo con una realización de la presente invención.
La Figura 15 es un diagrama que ilustra un ejemplo de una estructura de red de ProSe.
La Figura 16 es un diagrama de flujo que ilustra un procedimiento de recepción de un valor de Prioridad por Paquete de ProSe de acuerdo con una realización de la presente invención.
La Figura 17 es un diagrama de flujo que ilustra un procedimiento de recepción de información de PPP a través de un terminal remoto.
La Figura 18 es un diagrama que ilustra un ejemplo de una estructura de red de ProSe y una estructura de red de IMS y EPS.
La Figura 19 es un diagrama de flujo de asignación de una QoS apropiada a un portador de EPS para una retransmisión a través de una PCRF.
La Figura 20 es un diagrama que ilustra un procedimiento de permitir que un terminal remoto solicite una QoS apropiada a un portador de EPS para una retransmisión y asignación de la QoS al terminal remoto.
La Figura 21 es un diagrama de flujo de provisión de un valor ficticio para TAC y ECI a un encabezamiento de SIP. La Figura 22 es otro diagrama de flujo de provisión del valor ficticio para el TAC y el ECI al encabezamiento de SIP.
La Figura 23 es un diagrama de flujo que ilustra un ejemplo de un procedimiento de permitir que un UE remoto solicite un UE de retransmisión para adquirir valores de ECGI y TAC.
La Figura 24 es un diagrama de flujo que ilustra otro ejemplo del procedimiento de permitir que un UE remoto solicite un UE de retransmisión para adquirir valores de Ec G i y TAC.
La Figura 25 es un diagrama de configuración en bloques de un terminal de acuerdo con una realización de la presente invención.
La Figura 26 es un diagrama de configuración en bloques de entidad de red de acuerdo con una realización de la presente invención.
Modo para la invención
En la descripción de realizaciones de la presente invención, no se describirá una descripción de contenidos técnicos que se conocen bien en la técnica a la que pertenecen las realizaciones de la presente memoria descriptiva y no están directamente conectadas con las realizaciones de la presente invención. Esto es para transferir más claramente una esencia de las realizaciones de la presente memoria descriptiva mediante la omisión de una descripción innecesaria.
Se ha de entender que cuando un componente se denomina como que se "conecta a" o "acopla a" otro componente en la presente memoria descriptiva, puede significar que un componente se conecta directamente a o acopla directamente a otro componente o se conecta a o acopla eléctricamente a otro componente con el otro componente interpuesto entre los mismos. Además, en la presente memoria descriptiva, "que comprende" una configuración específica se entenderá que también puede incluirse una configuración adicional en las realizaciones o el ámbito de la idea técnica de la presente invención.
Adicionalmente, partes constitucionales mostradas en las realizaciones de la presente invención se muestran independientemente para representar diferentes funciones características. Por lo tanto, no significa que cada parte constitucional se constituye de una unidad constitucional de hardware separado o un software. Es decir, por conveniencia de descripción, las respectivas partes constitucionales se incluyen disponiéndose como cada parte constitucional y al menos dos partes constitucionales de las respectivas partes constitucionales pueden formar una parte constitucional o una parte constitucional se divide en una pluralidad de partes constitucionales para realizar funciones. Unas realizaciones integradas y una realización separada de las respectivas partes constitucionales también se incluyen en el ámbito de la presente invención a no ser que se alejen de la naturaleza de la presente invención.
Además, algunos de los constituyentes pueden no ser constituyentes indispensables que realizan funciones esenciales de la presente invención, sino ser constituyentes selectivos que mejoran únicamente el rendimiento de la misma. La presente invención puede implementarse incluyendo únicamente partes constitucionales esenciales para implementar la naturaleza de la presente invención distintas de los constituyentes usados únicamente para la mejora de rendimiento y la estructura que incluye únicamente los constituyentes esenciales distintos de los constituyentes selectivos usados únicamente para la mejora de rendimiento también se incluye en el ámbito de la presente invención.
En lo sucesivo, cuando se determina que en la descripción de las realizaciones de la presente invención, la descripción detallada de la técnica conocida relacionada con la presente invención puede obstaculizar la esencia de la presente invención, se omitirá la descripción detallada de la misma. En lo sucesivo, se describirán en detalle realizaciones de la presente invención con referencia a los dibujos adjuntos. Además, las siguientes terminologías se definen teniendo en cuenta las funciones en la presente invención y pueden interpretarse de diferentes formas por la intención de usuarios y operadores. Por lo tanto, las definiciones de las mismas deberían interpretarse a base de los contenidos a lo largo de toda la memoria descriptiva.
En este caso, puede entenderse que cada bloque de diagramas de flujo de procesamiento y combinaciones de los diagramas de flujo puede realizarse mediante instrucciones de programa informático. Ya que estas instrucciones de programa informático pueden instalarse en procesadores de un ordenador general, un ordenador especial u otros aparatos de procesamiento de datos programables, estas instrucciones de programa informático ejecutadas a través del procedimiento del ordenador o los otros aparatos de procesamiento de datos programable crean medios que realizan funciones descritas en el bloque o bloques del diagrama de flujo. Ya que estas instrucciones de programa informático también pueden almacenarse en una memoria usable por ordenador o una memoria legible por ordenador u otros aparatos de procesamiento de datos programables que pueden dirigir un ordenador u otros aparatos de procesamiento de datos programables para implementar funciones en un esquema específico, las instrucciones de programa informático almacenadas en la memoria usable por ordenador o la memoria legible por ordenador también pueden producir artículos de fabricación que incluyen medios de instrucciones que realizan las funciones descritas en el bloque o bloques del diagrama de flujo. Ya que las instrucciones de programa informático también pueden instalarse en un ordenador u otros aparatos de procesamiento de datos programables, realizan una serie de etapas de operación en el ordenador o los otros aparatos de procesamiento de datos programables para crear procedimientos ejecutados por el ordenador, de tal forma que las instrucciones de programa informático que ejecutan el ordenador o los otros aparatos de procesamiento de datos programables también pueden proporcionar etapas para la realización de las funciones descritas en el bloque o bloques del diagrama de flujo.
En este punto, el término '-unidad' usado en la presente realización significa software o componentes de hardware tales como FPGA y ASIC y la '~unidad' realiza cualquier función. Sin embargo, el significado de la '~unidad' no se limita a software o hardware. La '~unidad' puede configurarse para estar en un medio de almacenamiento que puede direccionarse y también puede configurarse para reproducir uno o más procesadores. Por consiguiente, como un ejemplo, la '~unidad' incluye componentes tales como componentes de software, componentes de software orientados a objeto, componentes de clase y componentes de función e incluye procesadores, funciones, atributos, procedimientos, subrutinas, segmentos de código de programa, controladores, firmware, microcódigo, circuito, datos, base de datos, estructuras de datos, tablas, matrices y variables. Las funciones proporcionadas en los componentes y las 'unidades' pueden combinarse con un número menor de componentes y las 'unidades' o pueden separarse adicionalmente en componentes adicionales y 'unidades'. Además, los componentes y las 'unidades' también pueden implementarse para reproducir una o más CPU dentro de un dispositivo o una tarjeta multimedia de seguridad.
Además, las realizaciones ilustrativas de la presente invención describirán principalmente en detalle la evolución a largo plazo (LTE) y el núcleo de paquete evolucionado (EPC) que son una red de acceso de radio (RAN) y una red principal (CN) definidas en la organización de Proyecto Común de Tecnologías Inalámbricas de la 3a Generación (3GPP). Sin embargo, un objeto principal de la presente invención puede aplicarse a incluso otros sistemas de comunicación que tienen los antecedentes técnicos similares con un pequeño cambio sin desviarse mucho del ámbito de la presente invención, que puede hacerse bajo la determinación de un experto en la materia a la que pertenece la presente invención.
Por ejemplo, un servicio de presionar para hablar de misión crítica (MCPTT) se describe principalmente como un ejemplo, pero la presente invención puede aplicarse generalmente a otros servicios sin un gran cambio. Toda la información transmitida a través de cada mensaje y etapa no se transfiere necesariamente y parte de la información definida puede transferirse si es necesaria.
Primero, se describirá un procedimiento y un aparato de registro de un usuario (por ejemplo, terminal) en una red de operador móvil y un servidor de aplicación.
Para que un usuario se conecte una red de comunicación móvil para usar un servicio, terminales de comunicación móvil (o equipo de usuario (UE), terminal o similar) necesitan registrarse en la red de operador móvil y el servidor de aplicación (AS). Existe una necesidad de autenticar si el usuario es un usuario que tiene la autoridad para usar el correspondiente servicio durante el registro. La presente invención proporciona el procedimiento de autenticación sobre si el usuario es un usuario que tiene la autoridad para usar el correspondiente servicio. Además, se proporciona un procedimiento para permitir que un núcleo de protocolo de iniciación de sesión (SIP) (función de control de sesión de llamada de intermediario mejorada (eP-CSCF), función de control de sesión de llamada de interrogación (I-CSCF), información de control de sesión de llamada de servicio (S-CSCF)) no conozca la identidad (o identificación) (ID) de presionar para hablar de misión crítica (MCPTT) de un usuario.
Para este fin, en la presente invención, se definen dos tipos de testigos. En este caso, los dos tipos de testigos pueden llamarse cada uno, por ejemplo, testigo A y testigo B. Como alternativa, los dos tipos de testigos también pueden llamarse un primer testigo y un segundo testigo o un testigo de primer tipo y un testigo de segundo tipo, o similar, pero no se limitan a los mismos. Por lo tanto, puede usarse cualquier término que puede diferenciar los dos tipos de testigos. En lo sucesivo, por conveniencia de descripción, el testigo A y el testigo B se usan para diferenciar los dos tipos de testigos. El testigo A y el testigo B pueden gestionarse mediante un servidor 130 de gestión de identidad (ID). Además, cuando el servidor 130 de gestión de ID recibe una petición desde un terminal 110, el servidor 130 de gestión de ID puede proporcionar un testigo al terminal 110. De acuerdo con la realización el terminal 110 también puede adquirir un testigo desde varios servidores 130 de gestión de ID.
En este caso, el testigo A puede ser un testigo usado a nivel de servicio de MCPTT. Si el terminal 110 transmite una petición de servicio que incluye el testigo A, un servidor 160 de MCPTT (o servidor de aplicación de MCPTT) puede derivar una ID de usuario de MCPTT a partir del correspondiente testigo A. Mediante el procedimiento, un proveedor de servicio de MCPTT puede ocultar la ID de usuario de MCPTT de los núcleos 140 y 150 de SIP.
El testigo B puede ser un testigo usado a nivel de SIP. Si no hay identidades de IMS requeridas para usar un servicio de subsistema multimedia del protocolo de internet (IMS IP), el terminal puede derivar y usar identidades de IMS del testigo B.
En lo sucesivo, se describirá en detalle un procedimiento de registro de un terminal en una red de operador móvil y un servidor de aplicación por etapas con referencia a los dibujos adjuntos.
La Figura 1 es un diagrama que ilustra un ejemplo de un procedimiento de registro de un terminal en una red de operador móvil y un servidor de aplicación, de acuerdo con una realización.
Haciendo referencia a la Figura 1, en la etapa 170, un usuario puede encender una fuente de alimentación del terminal 110. Por consiguiente, el terminal 110 puede realizar un procedimiento de conexión (autenticación) a una red 120 de comunicación móvil. Además, el terminal 110 puede conectarse a la red 120 de comunicación móvil para adquirir una dirección IP, adquirir de este modo conectividad IP.
En la etapa 171, el terminal 110 habilita un cliente de MCPTT. El terminal 110 conecta un identificador de recurso uniforme (URI) del servidor de gestión de ID para iniciar una conexión de protocolo de transferencia de hipertexto sobre capa de conexión segura (HTTPS). Una conexión de seguridad de capa de transporte (TLS) que usa e1HTTPS realiza autenticación de servidor unidireccional a base de un certificado de servidor. El cliente de MCPTT inicia un procedimiento de autenticación de usuario. El terminal 110 de MCPTT puede proporcionar información de credenciales de usuario (por ejemplo, biométricas, ID segura, nombre de usuario / contraseña o similar) al servidor 130 de gestión de ID para verificación.
En la etapa 172, el terminal 110 puede solicitar que se use el testigo A para el registro en el servidor 160 de MCPTT al servidor 130 de gestión de ID. En este caso, el terminal 110 puede transferir un testigo mensaje de petición que incluye la información que solicita el testigo A al servidor 130 de gestión de ID. Además, en la etapa 173, el terminal 110 puede recibir el testigo A desde el servidor 130 de gestión de ID como una respuesta al mismo. En este caso, el terminal 110 puede recibir un mensaje de respuesta de testigo que incluye el testigo A desde el servidor 130 de gestión de ID.
Cuando no hay información de credenciales de uso de IMS o la correspondiente información de credenciales puede no usarse para el registro de IMS, en la etapa 172, el terminal 110 puede solicitar adicionalmente el testigo B al servidor 130 de gestión de ID. Por lo tanto, en la etapa 173, el terminal 110 puede recibir el testigo B desde el servidor 130 de gestión de ID.
En este caso, de acuerdo con la realización, el terminal 110 puede recibir el testigo A y el testigo B desde el mismo servidor 130 de gestión de ID o diferentes servidores 130 de gestión de ID.
A continuación, en la etapa 174, el terminal 110 puede conectarse de forma segura con el núcleo 140 de SIP para la autenticación y registro del nivel de SIP. La Figura 1 ilustra ilustrativamente que el terminal 110 se conecta de forma segura con la eP-CSCF 140.
Además, en las etapas 175 y 176, el terminal 110 puede realizar el registro en los núcleos 140 y 150 de SIP usando la información de credenciales de uso de IMS o el testigo B.
Cuando se usa el testigo B, la eP-CSCF 140 puede derivar las identidades de IMS a partir del correspondiente testigo B. En este momento, las identidades de IMS derivadas a partir del testigo B pueden transferirse al terminal 110 mientras se incluyen en un mensaje de respuesta OK. Además, las identidades de IMS derivadas se usan en el mensaje de SIP transmitido desde el terminal 110. Mientras tanto, el terminal 110 puede transferir el testigo A incluido en el mensaje de registro de SIP a la S-CSCF 150.
A continuación, en la etapa 177, la S-CSCF 150 puede transferir el testigo A y las identidades de IMS al servidor 160 de MCPTT. El servidor 160 de MCPTT puede verificar el testigo A. Además, si el testigo A es válido, el servidor 160 de MCPTT puede derivar la ID de usuario de MCPTT a partir del testigo A. Además, la información de conexión entre la ID de usuario de MCPTT y las identidades de IMS puede gestionarse por el servidor 160 de MCPTT.
A continuación, se describirá un procedimiento de gestión de calidad de comunicación de grupo.
La Figura 2 es un diagrama que ilustra una realización de una interfaz de Rx de acuerdo con una realización.
Haciendo referencia a la Figura 2, un terminal 210 de usuario (o terminal, terminal de MCPTT, terminal de usuario de MCPTT) puede incluir un cliente 213 de SIP y un cliente 215 de HTTP. Además, el cliente 213 de SIP puede conectarse a un núcleo 230 de SIP a través de una interfaz 270 de SIP-1 y el cliente 215 de HTTP puede conectarse al servidor 250 de aplicación (AS) de HTTP. Además, el AS 250 de HTTP puede conectarse a otro AS de HTTP y una interfaz 285 de HTTP-2. Además, el núcleo 230 de SIP puede incluir una S-CSCF 231, I-CSCF 233, P-CSCF 235 y un servidor 237 de abonado doméstico (HSS). La P-CSCF 235 del núcleo 230 de SIP puede conectarse al terminal 210 a través de la interfaz 270 de SIP-1. Además, la S-CSCF 231 puede conectarse al servidor 240 de MCPTT a través de una interfaz 275 de SIP-2 y la S-CSCF 231 y la I-CSCF 233 pueden conectarse a una base de datos de usuarios de MCPTT a través de una interfaz de MCPTT-9. El núcleo 230 de SIP puede conectarse a otro núcleo (no ilustrado) a través de una interfaz 277 de SIP-3.
En este caso, en el sistema de comunicación móvil de LTE, para la gestión de QoS de una sesión de servicio de IMS proporcionada al terminal de usuario 210, puede definirse una primera interfaz 260 de Rx entre entidad 235 de P-CSCF y entidad 220 de función de reglas y políticas de tarificación (PCRF) (por ejemplo, Sistema de Paquetes Evolucionado (EPS)) y la QoS puede controlarse por la correspondiente interfaz 260.
En la presente invención, además de la estructura existente de sistema de comunicación móvil de LTE, se define una segunda interfaz 265 de Rx entre un servidor 240 de aplicación (servidor de MCPTT, servidor de aplicación de MCPTT) y la PCRF 220. Por lo tanto, pueden definirse la primera interfaz 260 de Rx entre la P-CSCF 235 y la PCRF 220 y la segunda interfaz 265 entre el servidor 240 de MCPTT y la PCRF 220. Por consiguiente, el servidor 240 de aplicación puede proporcionar requisitos de QoS a la PCRF 220 sin pasar a través de la PCCF 235. Para consistencia de operación de la PCRF 220, únicamente necesita usarse una de las interfaces 260 y 265 de Rx para el servidor 240 de aplicación y la P-CSCF 235 y puede preconfigurarse cuál de las dos interfaces 260 y 265 de Rx se usa.
Como se ilustra en la Figura 2, las interfaces 260 y 265 de Rx pueden definirse entre la PCRF 220 y la P-CSCF 235 y/o entre la PCRF 220 y el servidor 240 de MCPTT. En este caso, la PCRF 220 es difícil de operar mientras se recibe (transmite) información desde dos entidades (es decir, P-CSCF 235 y servidor de MCPTT 240). La razón es que cuando ambos del servidor 240 de MCPTT y la P-CSCF 235 transmiten información inconsistente a la PCRF 220, es difícil que la PCRF 220 procese la información recibida. Por el contrario, si las dos entidades 235 y 240 proporcionan la misma información, una de las dos entidades 235 y 240 genera señalización irrelevante, que puede no considerarse como una operación preferida. Por lo tanto, una de las dos entidades 235 y 240 necesita seleccionarse sobre la base de una política de operador y/u otro criterio preconfigurado.
Se necesitan tanto la o las ID de PLMN de servicio como doméstica para identificar el punto de contacto para las interfaces 260 y 265 de Rx, además de parámetros existentes como se definen en TS 23.203. El AS 240 de MCPTT encuentra el punto de entrada en la HPLMN usando la ID de PLMN doméstica, el AS 240 de MCPTT encuentra el punto de entrada en la VPLMN usando la ID de PLMN de servicio. Dentro de la PLMN, la información listada en TS 23.203 se usa para encontrar la PCRF 220.
El AS 240 de MCPTT se configura con información de correlación que contiene un intervalo de direcciones IP y la correspondiente PLMN que es responsable de este intervalo de direcciones IP {(IP x .. IP y) -> PLMN ID}.
En escenarios de itinerancia, el AS 240 de MCPTT recibe la dirección IP de UE, la ID de HPLMN y la ID de VPLMN a través de señalización de MCPTT-1 desde el UE 210. Si la entrada de PLMN configurada que corresponde a la dirección de IP del UE coindice con la ID de HPLMN enviada por el UE 210, el AS 240 de m CpTT selecciona una PCRF 220 desde la HPLMN del UE (hPCRF) usando los procedimientos definidos en TS 23.203. De otra manera, el AS 240 de MCPTT puede seleccionar una PCRF 220 de o bien la HPLMN o bien la VPLMN usando los procedimientos definidos en TS 23.203. El AS 240 de MCPTT hace esta selección a base de acuerdos con operadores de HPLMN/VPLMN.
La información a transferir a través de las interfaces 260 y 265 de Rx puede ser como se indica a continuación.
- Descripción de medios o flujo (por ejemplo, SDP);
- Prioridad;
- ID de Grupo de MCPTT;
- ID de Usuario de MCPTT y/o IMPU; y/o
- Tipo de llamada.
El AS 240 de MCPTT puede transferir directamente toda o parte de la información a la PCRF 220 a través de la segunda interfaz 265 de Rx, y el AS 240 de MCPTT puede transferir toda o parte de la información al núcleo 230 de SIP a través de la SIP-2275 y, por lo tanto, la P-CSCF 235 puede transferir toda o parte de la información a la PCRF 220 a través de la primera interfaz 260 de Rx. Además, la PCRF puede establecer nuevamente un portador o modificar el portador existente, de acuerdo con la información recopilada.
A continuación, se describirá un procedimiento de transferencia eficiente de señalización relacionada con difusión.
La Figura 3 es un diagrama que ilustra un ejemplo de un procedimiento de transferencia de señalización relacionada con difusión de acuerdo con una realización.
Haciendo referencia a la Figura 3, en la etapa 370, el equipo 310 de usuario (UE) puede transmitir una lista de identificador global de célula de EUTRAN a un servidor 360 de aplicación de servicio de comunicación de grupo (AS de GCS). En este caso, la lista de ECGI puede incluir una lista de ECGI. Además, el AS 360 de GCS puede definir si transmitir la lista de ECGI a un centro 350 de servicio de multidifusión de difusión de acuerdo con información de configuración. La información de configuración puede estar disponible en el AS 360 de GCS de acuerdo con la política de operador y por el procedimiento de implementación. Además, de acuerdo con la realización, de la presente invención, la información de configuración también puede estar disponible en el AS 360 de GCS mediante la señalización entre el BM-SC 350 y el AS 360 de GCS.
Para que el AS 360 de GCS active un portador de servicio de multidifusión de difusión multimedia (MBMS) a través de la interfaz de MB2, en la etapa 371, el AS 360 de GCS puede transmitir un mensaje de petición de activación de portador de MBMS al BM-SC 350.
En este caso, el mensaje de petición de activación de portador de MBMS puede incluir al menos uno de identificador de grupo móvil temporal (TMGI), ID de flujo, QoS, un área de difusión de MBMS y un tiempo de inicio de MBMS. El TMGI puede identificar el portador de MBMS. La ID de flujo se incluye en el mensaje de petición de activación de portador de MBMS únicamente cuando el TMGI se incluye en el mensaje de petición de activación de portador de MBMS y puede usarse para diferenciar un flujo específico en tráfico de MBMS que corresponde al TMGI. Si la ID de flujo se incluye en el mensaje de petición de activación de portador de MBMS, el BM-SC 350 puede asociar la ID de flujo con el TMSI transferido desde el mensaje de petición de activación de portador de MBMS y asociar la ID de flujo con el área de difusión de MBMS. El valor de QoS puede correlacionarse con un valor que representa prioridad del portador de MBMS. Si el área de difusión de MBMS incluye una lista de ID de célula, el b M-SC 350 correlaciona la ID de célula con un conjunto de áreas de servicio (SA) de MBMS. De acuerdo con la realización el AS 360 de GCS puede transmitir la SA de MBMS cuando se transfiere la lista de ECGI al BM-SC 350. El BM-SC 350 puede ignorar la SA de MBMS recibida desde la SA 360 de GCS y reescribir la SA de MBMS obtenida como se describe anteriormente a la SA de MAMS recibida desde la SA 360 de GCS. Cuando se recibe la lista de ECGI, el BM-SC 350 puede transmitir la SA de MBMS al AS 360 de GCS mientras pone la SA de MBMS en el mensaje de respuesta de activar portador de MNMS. Usando esto, el AS 360 de GCS puede usarse para configurar los datos de servicio de MBMS. Cuando no recibe la lista de ECGI, el BM-SC 350 no pone la SA de MBMS en el mensaje de respuesta de activar portador de MNMS.
En la etapa 372, el BM-SC 350 puede correlacionar la lista de ID de célula (es decir, ECGI de la lista de ECGI) con una lista de áreas de servicio (SAI) y puede determinar al menos una pasarela 340 de MBMS (MBMS-GW) para un área relacionada.
Además, en la etapa 373, el BM-SC 350 puede transmitir un mensaje de inicio de sesión a la o las MBMS-GW 340 determinadas en la etapa 372. El mensaje de inicio de sesión puede incluir un parámetro relacionado con MBMS que cumple con la Versión 12 de 3GPP. Además, de acuerdo con la realización, el mensaje de inicio de sesión puede incluir la lista de ID de célula (es decir, lista de ECGI).
En la etapa 374, la MBMS-GW 340 puede transmitir el mensaje de inicio de sesión a la entidad 330 de gestión de movilidad (MME) implicada. El mensaje de inicio de sesión puede incluir el parámetro relacionado con MBMS que cumple con la Versión 12 de 3GPP. Además, de acuerdo con la realización, el mensaje de inicio de sesión puede incluir la lista de ID de célula (es decir, lista de ECGI).
Además, en la etapa 375, una MME 330 puede transmitir el mensaje de inicio de sesión a la entidad 320 de coordinación de multidifusión multicélula implicada (MCE implicada o implicadas). El mensaje de inicio de sesión puede incluir el parámetro relacionado con MBMS que cumple con la Versión 12 de 3GPP. Además, de acuerdo con la realización, el mensaje de inicio de sesión puede incluir la lista de ID de célula (es decir, lista de ECGI).
Mientras tanto, cuando se elige un objeto de recepción del mensaje de inicio de sesión, la MME 330 puede usar la lista de ECGI y la SA de MBMS recibidas en la etapa 374. La MME 330 puede recibir un identificador de MEC al que se conecta la estación base (Nodo B evolucionado (eNB)) o el identificador de MEC al que se conecta una célula dentro de la estación base durante un establecimiento de S1 o una actualización de configuración de eNB. Como alternativa, la MME 330 puede recibir una célula o una lista de estaciones base conectada a una MCE 320 durante un establecimiento de M3 o una actualización de configuración de MCE. Usando la información, la MME 330 puede transferir el mensaje de inicio de sesión únicamente a la estación base (no ilustrada) que corresponde a la lista de ECGI recibida. La MME 330 puede identificar la estación base mirando una porción de ID de eNB global del ECGI. Por lo tanto, la MME 330 puede elegir la MCE 320 adecuada usando información de MCE de servicio e información de ECGI para cada estación base durante el establecimiento de S1 o la actualización de configuración de eNB.
A continuación, en la etapa 376, la MCE 320 puede correlacionar la lista de SAI recibida desde el mensaje de inicio de sesión recibido desde la MME 330 a una difusión multidifusión a través de una lista de red de frecuencia única (MBSFN) y eliminar la MBSFN que no se usa en la correspondiente lista de ECGI. La MCE 320 puede asignar recursos para el portador de MBMS a la o las MBSFN asignadas o seleccionadas. Además, la MCE 320 puede almacenar la lista de ID de célula (es decir, lista de ECGI) de la MBSFN en la que se activa el portador de MBMs .
En la etapa 377, la MCE 320 puede transferir un mensaje de respuesta de inicio de sesión a la MME 330. El mensaje de respuesta de inicio de sesión puede incluir el parámetro relacionado con MBMS que cumple con la Versión 12 de 3GPP. Además, de acuerdo con la realización, el mensaje de respuesta de inicio de sesión puede incluir la lista de ID de célula (es decir, lista de ECGI) en la que se activa el portador de MBMS.
Además, en la etapa 378, la MME 330 puede transferir el mensaje de respuesta de inicio de sesión a la MBMS-GW 340. El mensaje de respuesta de inicio de sesión puede incluir el parámetro relacionado con MBMS que cumple con la Versión 12 de 3GPP. Además, de acuerdo con la realización, el mensaje de respuesta de inicio de sesión puede incluir la lista de ID de célula (es decir, lista de ECGI) en la que se activa el portador de MBMS por el mensaje de respuesta de inicio de sesión.
A continuación, en la etapa 379, la MBMS-GW 340 puede transferir el mensaje de respuesta de inicio de sesión al BM-SC 350. El mensaje puede incluir el parámetro relacionado con MBMS que cumple con la Versión 12 de 3GPP. Además, de acuerdo con la realización, el mensaje de respuesta de inicio de sesión puede incluir la lista de ID de célula (es decir, lista de ECGI) en la que se activa el portador de MBMS por el mensaje de respuesta de inicio de sesión.
En la etapa 380, el BM-SC 350 puede transmitir el mensaje de respuesta de activar portador de MNMS al AS 360 de GCS. El mensaje de respuesta de activar portador de MNMs puede incluir al menos uno de TMGI, ID de flujo (si la ID de flujo se incluye en el mensaje de petición de activación de portador de MBMS, el mensaje de respuesta de activar portador de MNMS puede incluir el mismo valor de la ID de flujo incluida en el mensaje de petición de activación de portador de MBMS. O el mensaje de respuesta de activar portador de MNMS puede incluir la ID de flujo asignada desde el BM-SC 350), descripción de servicio de MBMS, una dirección IP y un número de puerto del BM-Sc 350 para un plano de transmisión de datos de usuario y tiempo de expiración. La descripción de servicio de MBMS incluye información de configuración relacionada con portador de MBMs , que puede incluir al menos una de información (por ejemplo, área de servicio de MBMS, radiofrecuencia, dirección de multidifusión de IP, APN o similar) dispuesta en TS 26.346. Cuando el BM-SC 350 asigna el TMGI, el tiempo de expiración representa tiempo de expiración del correspondiente TMGI. Si el BM-SC 350 recibe la lista de ECGI en la etapa 371, el BM-SC 350 puede incluir la lista de ECGI en el mensaje de respuesta de activar portador de MNMS mediante el procedimiento.
Si el BM-SC 350 transmite el mensaje de respuesta de activar portador de MNMS en la etapa 379 antes de recibir el mensaje de respuesta de inicio de sesión y la lista de ECGI incluida en el mensaje de respuesta de inicio de sesión recibido en la etapa 379 es diferente de la lista de ECGI incluida en el mensaje de petición de activación de portador de MBMS recibido en la etapa 371, el BM-SC 350 puede transmitir el mensaje de respuesta de activar portador de MNMS que incluye la lista de ECGI recibida en la etapa 379 al AS 360 de GCS y actualizar el mensaje de respuesta de activar portador de MNMS transmitido para notificar al AS 360 de GCS la lista de ECGI en la se activa un portador de MNMS actual.
La Figura 4 es un diagrama que ilustra un procedimiento de establecimiento de SI entre una estación base y una MME de acuerdo con una realización, la Figura 5 es un diagrama que ilustra un procedimiento de actualización de configuración de eNB entre la estación base y la MME de acuerdo con una realización, la Figura 6 es un diagrama que ilustra un procedimiento de establecimiento de M3 entre la estación base y la MME de acuerdo con una realización, y la Figura 7 es un diagrama que ilustra un procedimiento de actualización de configuración de MCE entre una MCE y la MME de acuerdo con una realización.
La información de MCE 320 servida por una estación 315 base puede intercambiarse entre la estación 315 base y la MME 330 usando el siguiente procedimiento y mensaje.
Haciendo referencia a la Figura 4, en la etapa 410, la estación 315 base puede transmitir un mensaje de petición de establecimiento de S1 a la MME 330 y, en la etapa 420, la estación 315 base puede recibir un mensaje de respuesta de establecimiento de S1 desde la m Me 330.
En este caso, el mensaje de petición de establecimiento de S1 puede definirse como las siguientes [Tabla 1] y [Tabla 2].
Tabla 1
Figure imgf000009_0001
Tabla 2
Figure imgf000009_0002
Además, haciendo referencia a la Figura 5, en la etapa 510, la estación 315 base puede transmitir el mensaje de actualización de configuración de eNB a la MME 330 y, en la etapa 520, recibir una actualización de configuración de eNB mensaje de acuse de recibo desde la MME 330.
En este caso, el mensaje de actualización de configuración de eNB puede formarse como las siguientes [Tabla 3] y [Tabla 4].
Tabla 3
T l
Figure imgf000010_0001
Tabla 4
Figure imgf000010_0002
Mientras tanto, haciendo referencia a la Figura 6, en la etapa 610, la MCE 320 puede transmitir un mensaje de petición de establecimiento de M3 (petición de establecimiento de S1) a la MME 330 y, en la etapa 620, la MCE 320 puede recibir un mensaje de respuesta de establecimiento de M3 (respuesta de establecimiento de S1) desde la MME 330. Además, haciendo referencia a la Figura 7, en la etapa 710, la MCE 320 puede transmitir un mensaje de actualización de configuración de MCE a la MME 330 y en la etapa 720, la MCE 320 puede recibir un mensaje de acuse de recibo de actualización de configuración de MCE desde la MME 330.
Mientras tanto, la ID de MCE global puede definirse como la siguiente [Tabla 5]. La ID puede usarse en el momento del establecimiento del establecimiento de M3 entre la MCE 320 y la m Me 330 o actualización de la configuración de MCE.
Tabla 5
[Tabla 5]
Figure imgf000011_0001
En este caso, el mensaje de petición de establecimiento de M3 puede definirse como las siguientes [Tabla 6] y [Tabla 7].
Tabla 6
Figure imgf000012_0001
Tabla 7
T l 71
Figure imgf000013_0001
Además, el mensaje de actualización de configuración de MCE puede formarse como las siguientes [Tabla 8] y [Tabla 91.
Tabla 8
Figure imgf000014_0001
Tabla 9
[Tabla 9]
Figure imgf000015_0001
A continuación, se describirá un procedimiento de gestión de calidad de comunicación de grupo.
A lo largo de toda la presente memoria descriptiva, la CIoT representa un servicio de IoT (IoT celular) que usa una red celular. La red celular significa una red de comunicación móvil e incluye 2G representada por GERAN, 3G representada por GPRS y 4G representada por LTE. El servicio de CIoT puede significar un servicio celular de soporte de un terminal de Internet de las Cosas (IoT) y puede significar un servicio que transmite una pequeña capacidad de datos a través de la red celular. Además, el servicio de CIoT puede incluir un servicio de comunicación entre máquinas (MTC).
La CIoT es que un gran número de terminales pueden conectarse simultáneamente a la red y la red puede transferir simultáneamente datos a un gran número de terminales. Por lo tanto, se espera que una situación de congestión de red puede ser más grave que un sistema celular general. Por lo tanto, se requieren un procedimiento de reducción de una situación de congestión debido a CIoT mediante el establecimiento y señalización entre aparato de redes y un procedimiento de procesamiento de prioridades dependiendo de una clase de tráfico de CIoT en una situación de congestión. La clase de tráfico de CIoT puede incluir unos datos de informe periódicos, unos datos notificados cuando se genera un evento periódico, unos datos de comando que emiten un comando a través de la red para permitir que un aparato desencadene una operación específica, unos datos de actualización para actualizar software / firmware de un aparato de IoT y cambiar un establecimiento del mismo, unos datos para seguridad pública o similares. Para aumentar la calidad de servicio en la situación de congestión de red, unos datos de CIoT dependiendo de las necesidades de evento aperiódicas a transferirse preferencialmente a través de la red a través de fatos de CIoT transferidos periódicamente. De otra manera, un usuario puede recibir tarde unos datos de CIoT dependiendo de unos datos aperiódicos que notifican tarde la ocurrencia de la situación de emergencia debido a la congestión de los datos de CIoT transferidos periódicamente, que pueden provocar la reducción en la calidad de servicio y falibilidad que el usuario siente.
Por conveniencia, en la presente invención, unos datos de plano de usuario transmitidos desde un terminal se llaman unos datos y unos datos de plano de control se llaman señalización. El término no se limita al nombre y pueden usarse otros términos que dividen un paquete transmitido para proporcionar unos datos y una señal de control transmitida para proporcionar un servicio en una red. Además, por conveniencia de explicación, se ilustran un término que indica información de control usada en la siguiente descripción, un término que indica unos datos de usuario transferidos a un servidor de aplicación, un término que indica señalización para la transferencia de información de control entre aparatos de red, un término (por ejemplo, datos de informe de evento, datos de informe periódicos) que indica una clase de tráficos, un término que indica componentes de un aparato, etc. Por consiguiente, la presente invención no se limita a términos a describirse a continuación y pueden usarse otros términos que tienen el significado técnico equivalente.
Además, pueden usarse algunos de los términos y nombres definidos en la Evolución a Largo Plazo del Proyecto Común de Tecnologías Inalámbricas de la 3a Generación (3GPP LTE). Sin embargo, la presente invención no se limita a los términos y nombres, sino también pueden aplicarse idénticamente al sistema de acuerdo con otras normas.
La Figura 8 es un diagrama que ilustra un ejemplo de una estructura de red que soporta un servicio de CIoT de acuerdo con una realización y la Figura 9 es un diagrama que ilustra otro ejemplo de la estructura de red que soporta un servicio de CIoT de acuerdo con una realización.
El terminal 817 de LTE y el terminal 810 de IoT significan un terminal móvil que puede realizar comunicación de radio y puede ser, por ejemplo, un asistente digital personal (PDA), un teléfono inteligente, un teléfono móvil, un ordenador de tableta, un ordenador portátil, etc., que incluyen una función de comunicación y pueden significar un terminal de medición para la confirmación de consumo de agua, consumo de electricidad y temperatura, un terminal para el reconocimiento y notificación de una situación tal como un dispositivo de alarma contra incendios y dispositivo de alarma de terremotos, y electrodomésticos que tienen una función de comunicación tal como un aire acondicionado, un refrigerador, un depurador de aire, una caldera y un limpiador, además de equipo individual. Además de las clases anteriormente mencionadas, todas las cosas que pueden realizar comunicaciones se llamarán como el terminal de IoT en la presente invención. Además, el terminal que usa la red celular entre los terminales de IoT se llama el terminal de CIoT. Además, por conveniencia de explicación, las expresiones del terminal de CIoT, el terminal de IoT, el terminal, el terminal de usuario o similares pueden usarse juntas. El terminal 810 de CIoT puede significar el terminal que transmite una pequeña capacidad de datos en la red LTE. El aparato, función y operación para un servicio de CIoT de acuerdo con la presente invención incluyen un aparato, una función y una operación para una pequeña transmisión de datos en la red LTE. Los datos de IoT pueden significar unos datos que el terminal de IoT transmite o una pequeña capacidad de datos que cualquier clase de terminales transmiten.
Para la CIoT, el equipo de red existente puede cambiarse. Por ejemplo, puede estar presente una estación base especializada para CIoT y puede estar presente una estación base en la que se añade una función de CIoT a la estación base existente. En la presente invención, la estación base especializada para CIoT se llama una C-BS 820 por conveniencia. La estación base en la que se añade la función de CIoT a la estación base existente se llama un C-eNB 825 por conveniencia. La presente invención no se limita a los términos correspondientes y, por lo tanto, pueden usarse otros términos que tienen el significado técnico equivalente. De manera similar, también puede usarse una red principal presente en la red celular únicamente para la CIoT. En la presente invención, esto se llama un nodo 830 de red principal (CN) de CIoT y se llama un C-SGN en la presente 3GPP, pero la presente invención no se limita al término correspondiente, sino que pueden usarse otros términos que tienen el significado técnico equivalente. El nodo 830 de CN de CIoT puede no realizar únicamente gestión de contexto, gestión de movilidad y gestión de sesión de señalización del terminal 810 de CIoT, sino también puede transferir los datos del terminal 810 a un servidor 840 de aplicación (AS) o transferir los datos recibidos desde el servidor 840 de aplicación al terminal 810. Es decir, el nodo 830 de CN de CIoT puede proporcionar funciones de pasarelas (GW) 865 y 867 al terminal de CIoT y realizar una función de una S-GW 865 / P-GW 867 de recepción de unos datos desde la C-BS 820 o el C-eNB 825 y encaminamiento de los datos recibidos al servidor 840 de aplicación. En este caso, como se ilustra en la Figura 8, el nodo 830 de CN de CIoT puede conectar el terminal 810 de CIoT a un plano de señalización y puede no conectar el terminal de CIoT a un plano de usuario y puede transmitir los datos de CIoT al plano de señalización o puede transmitir una pequeña capacidad de datos al plano de señalización.
Además, como se ilustra en la Figura 9, cuando el nodo 830 de CN de CIoT establece tanto la conexión del terminal 810 de CIoT al plano de señalización y la conexión del terminal 810 de CIoT al plano de usuario, el terminal 810 de CIoT establece un portador para el plano de usuario con la C-BS 820 o el C-eNB 825 y la C-BS 820 o el C-eNB 825 establece el portador para el plano de usuario con la S-GW 865 / P-GW 867. En este caso, el terminal 810 de CIoT puede transmitir los datos de plano de usuario a través de la C-BS 820 o el C-eNB 825 y la C-BS 820 o el C-eNB 825 encamina los datos de plano de usuario a la S-GW 865 / P-GW 867 para soportar comunicación de datos.
El nodo 830 de CN de CIoT realiza una función similar a la MME 860 de la red LTE existente. De acuerdo con la realización, el nodo 830 de CN de CIoT puede ser un aparato en el que la función de CIoT se añade a la MME 860 proporcionando la tecnología equivalente. El nodo 830 de CN de CIoT puede conectarse a varias C-BS 820 y varios C-eNB 825. Es evidente que en el 3GPP, esto se llama una conexión S1 y puede ser otro término que indica una interfaz entre la C-BS 820 o el C-eNB 825 y el nodo 830 de CN de CIoT. El C-eNB 825 es una estación base que soporta el servicio de CIoT, pero también soporta un servicio LTE general. Por lo tanto, el terminal 810 de CIoT y el terminal 817 de LTE general también pueden conectarse al C-eNB 825 para usar un servicio de comunicación. Por otra parte, la C-BS 820 es una estación base que soporta únicamente el servicio de CIoT y, por lo tanto, el terminal 817 de LTE general no se conecta y únicamente el terminal 810 de CIoT se conecta a la C-BS 820 para usar un servicio de comunicación. El nodo 830 de CN de CIoT no encuentra si las estaciones 820 y 825 base son la estación 820 base especializada para CIoT o la estación base general, reconoce que la conexión S1 se establece para transmitir señalización o datos. El nodo 830 de CN de CIoT primero transfiere señalización de radiobúsqueda a la C-BS 820 o al C-eNB 825 conectado más recientemente a los terminales 810, 815 y 817 para transmitir datos o señalización. Si falla la primera señalización de radiobúsqueda, el nodo 830 de CN de CIoT transmite la señalización de radiobúsqueda a todas las estaciones 820 y 825 base en el área en la que los terminales 810, 815 y 817 están presentes para transmitir radiobúsqueda a los terminales 810, 815 y 817. En este caso, el C-eNB 825 que está proporcionando el servicio de LTE general junto recibe la señalización de radiobúsqueda a pesar de que la señalización de radiobúsqueda no es para los terminales 815 y 817 servido por el propio C-eNB. En este caso, la innecesaria señalización de radiobúsqueda puede provocar la congestión en el C-eNB 825 que proporciona el servicio de LTE general para reducir la calidad de servicio del usuario de servicio de LTE general. Por lo tanto, después de que falla la señal de radiobúsqueda, el nodo 830 de CN de CIoT puede transmitir primero la señalización de radiobúsqueda a la C-BS 820 para evitar que se produzca la congestión en el C-eNB 825 que proporciona el servicio de lTe general. Para la operación como se describe anteriormente, cuando el nodo 830 de CN de CIoT se conecta por SI a la C-BS 820 o al C-eNB 820, la estación base puede diferenciar y notificar su propia capacidad, de tal forma que es posible diferenciar si la estación base a la que se conecta por S1 el nodo 830 de CN de CIoT es la estación 820 base para CIoT (C-BS) especializada o la estación 825 base (C-eNB) de soporte de CIoT que también proporciona el servicio general.
En lo sucesivo, se describirá un procedimiento de división de una clase de tráficos de CIoT para realizar preferencialmente una transmisión de tráfico específica y un procedimiento de división de equipo de red para CIoT y equipo de red general que soporta una CIoT para permitir que el equipo de red para CIoT procese más señalización relacionada con CIoT.
La realización principalmente describe el sistema de LTE definido en el 3GPP, pero puede aplicarse de forma similar en comunicaciones de radio tales como WLAN y Bluetooth. De acuerdo con la presente invención, se describirán un procedimiento y un aparato de intercambio de información relacionada con retransmisión entre una red principal y una estación base para soportar una función de retransmisión de UE a red que es una de funciones de servicio basado en proximidad (ProSe) para seguridad pública y un procedimiento y un aparato de control de un terminal para permitir que una estación base soporte una función de retransmisión.
El tráfico de CIoT puede tener una tasa de datos baja, poca capacidad, tolerancia a retardo, (evento de) periodicidad / aperiodicidad, características requeridas / no requeridas de respuesta. En más detalle, el tráfico de datos que realiza informes de eventos tales como alarma de humos, alarma de fallos, alarma de corte de potencia y alarma de temperatura puede transmitir una pequeña capacidad de datos únicamente a un enlace ascendente, puede no requerir una respuesta, y no se produce todo el tiempo, pero puede producirse únicamente cuando se genera un evento. El tráfico puede usarse en el servicio de IoT asociado con seguridad pública y, por lo tanto, puede tener una mayor prioridad que otro tráfico de datos. Además, el tráfico de datos que realiza un informe periódico tal como medición de consumo de gas, medición de consumo de agua y medición de consumo de electricidad puede transmitir una pequeña capacidad de datos a un enlace ascendente, recibir una respuesta a un resultado del informe de medición, y puede generarse periódicamente todo el tiempo en una unidad de minuto / hora / día / mes / año. El tráfico de datos que enciende / apaga una fuente de alimentación del terminal o desencadena la operación específica puede transmitir una pequeña capacidad de datos a un enlace ascendente, recibir una respuesta a rendimiento de operación a través de a enlace descendente, y puede generarse periódica o aperiódicamente. Los datos necesitan realizarse permitiendo que el terminal de CIoT emita un comando o reciba el comando y, por lo tanto, si los datos no se transfieren dentro de un tiempo predeterminado, es demasiado tiempo para desencadenar el dispositivo para reducir la calidad de servicio de IoT, de tal forma que el tráfico de datos necesita procesarse preferencialmente a través de otro tráfico de datos en la red. El tráfico de datos para la actualización de software / firmware, actualización de un valor establecido, etc. del terminal de IoT puede usar la relativamente grande capacidad como el enlace ascendente y el enlace descendente y es el tráfico de datos que se produce relativamente de forma intermitente. El tráfico de datos puede usarse para actualizar la información relacionada con seguridad, actualizar el establecimiento para el equipo de IoT añadido dentro de la red de enfoque de IoT, etc.
La realización propone la categorización de tráfico de datos. En este caso, el terminal de CIoT y la red pueden aplicar otras prioridades dependiendo de la categoría de tráfico de datos para procesar los datos de IoT. La categoría de tráfico de datos puede dividirse de acuerdo con las características de datos anteriormente mencionadas. La siguiente Tabla 10 es un ejemplo que muestra la categoría dependiendo de atributos de tráfico de datos.
Tabla 10
T l 11
Figure imgf000017_0001
La categoría de la Tabla 10 anterior divide datos a base de capacidad / periodicidad / necesidad de respuesta / seguridad pública / emergencia y pueden no depender necesariamente de la división como se describe anteriormente y significar todas las categorías que pueden dividirse dependiendo de al menos un atributo de tráfico de capacidad / periodicidad / necesidad de respuesta / seguridad pública / emergencia.
Puede esperarse que los datos de IoT generalmente tengan poca capacidad, pero todos los datos de IoT pueden no transmitirse por un paquete y puede transmitirse y recibirse una gran cantidad de datos en el caso de actualización del establecimiento del equipo o actualización del software. Por lo tanto, puede dividirse si los datos de IoT pueden incluirse en un paquete o varios paquetes, o se requiere si una gran capacidad de datos. En la presente invención, también se incluye cualquier división que depende de los datos capacidad.
Los datos de IoT pueden ser unos datos que se transmiten y reciben a y desde equipo pequeño tal como un sensor o equipo de medición y el equipo puede transmitir unos datos cuando el valor medido se notifica periódicamente o se produce la situación específica. Por ejemplo, el terminal de IoT que mide consumo de agua y consumo de electricidad puede transmitir el informe de medición en un periodo de 1 día, 1 semana o 1 mes. Cuando el terminal de IoT que puede transmitir una alarma contra incendios y una alarma de terremotos detecta humo o es igual a o mayor que una temperatura específica o detecta un temblor fuerte, el terminal de IoT puede notificar los datos pertinentes y, por lo tanto, generar unos datos cuando se produce la situación específica sin periodicidad. Por lo tanto, el tráfico de datos que el terminal de IoT notifica puede tener periodicidad o puede generarse como tráfico de datos orientado a evento y puede subdividirse en una unidad de minuto, hora, día, mes, año, etc., cuando tiene periodicidad.
El terminal de IoT puede transmitir unos datos que no requieren una respuesta a los datos transmitidos. Por ejemplo, cuando se notifica el valor medido, únicamente se transmite el valor medido y puede no requerirse la respuesta al mismo. Como alternativa, el terminal de IoT puede transmitir los datos que requieren la respuesta a los datos. Por ejemplo, cuando se consulta una temperatura actual dentro de una casa para un aire acondicionado que soporta el servicio de IoT, el aire acondicionado que recibe la consulta necesita responder a la temperatura actual. Como alternativa, cuando se consulta al aire acondicionado para que opere, el aire acondicionado puede transmitir la respuesta de que se procesa bien un comando para notificar a un usuario que un comando se realiza bien. Por lo tanto, los datos que el terminal de loT transmite pueden dividirse dependiendo de si se requiere o no la respuesta.
El terminal de IoT puede usarse para un fin comercial tal como una casa inteligente y una red inteligente y un fin de seguridad pública / emergencia para percibir un desastre natural o un accidente. Por ejemplo, cuando se produce un incendio o un terremoto en regiones escasamente pobladas, un pequeño terminal instalado alrededor de las mismas puede detectar una situación para transmitir un informe. Cuando se produce la situación en la que se amenaza la seguridad pública, el procesamiento de la misma necesita realizarse más rápidamente que otros datos. Por lo tanto, si el terminal de IoT transmite el tráfico de datos para la seguridad pública o la emergencia, el terminal de IoT puede designar la categoría de tráfico de modo que el tráfico de datos se procesa preferencialmente sobre el tráfico de datos comercial general. La presente invención incluye la división de las características del terminal de IoT usando al menos uno de los atributos listados (capacidad / periodicidad / necesidad de respuesta / seguridad pública / emergencia). Además, la presente invención incluye el procesamiento que cumple con las características en la red a base de las características divididas.
Mientras tanto, las características de tráfico pueden interpretarse como la prioridad de los datos de IoT que el terminal de IoT transmite. Es decir, los datos para la emergencia o los datos públicos necesitan procesarse preferencialmente sobre los datos de informe de medición generales. Por lo tanto, las características de tráfico pueden sustituirse en la prioridad de los datos y aplicarse a continuación. Por ejemplo, el valor de QCI puede asignarse a cada clase de datos usando un identificador de clase de QoS (QCI) que es un índice que representa la QoS, aplicando de este modo la prioridad. Como un ejemplo más detallado, puede asignarse QCI = 6 a los datos para la seguridad pública y puede asignarse QCI = 9 a los datos de informe de medición generales. El terminal puede transmitir datos que incluyen el valor de QCI y la estación base, la MME o el SGSN que percibe los datos preferencialmente procesa datos para QCI = 6 sobre datos para QCI = 9, aplicando de este modo la prioridad.
La Figura 10 es un diagrama que ilustra un procedimiento de permitir que un nodo de CN de CIoT adquiera información de suscripción que incluye un tipo que divide tráfico de datos de acuerdo con fin o características del terminal de CIoT desde h Ss cuando un terminal de CIoT realiza una petición de servicio/actualización de área de seguimiento/conexión, de acuerdo con una realización.
De acuerdo con la realización ilustrada en la Figura 10, la categoría de tráfico de datos puede usarse en la red mientras se almacena como información de suscripción de un terminal 810 de CIoT.
En la etapa 1010, puede establecerse una conexión de RRC entre el terminal 810 de CIoT y la C-BS 820.
Además, en la etapa 1020, el terminal 810 de CIoT puede transmitir una petición de conexión a conectarse al nodo 820 de CN de CIoT. Como alternativa, se cambia la posición del terminal 810 de CIoT y, por lo tanto, el terminal 810 de CIoT puede transmitir una actualización de área de seguimiento al nodo 820 de CN de CIoT. Como alternativa, el terminal 810 de CIoT puede transmitir una petición de servicio para transmitir datos al nodo 820 de CN de CIoT.
Además, en la etapa 1030, el nodo 820 de CN de CIoT puede realizar un procedimiento de autenticación en e1HSS 350. En este caso, el nodo 820 de CN de CIoT puede recibir la información de suscripción que incluye la división de acuerdo con las características de tráfico de datos usadas por el terminal 810 de CIoT desde e1HSS 850. Además, el nodo 820 de CN de CIoT puede almacenar, como un contexto de terminal en la etapa 1040, la información de suscripción que incluye la división de acuerdo con las características de tráfico de datos recibidas en la etapa 1030 y usadas por el terminal 810 de CIoT. Además, en la etapa 1050, el nodo 820 de CN de CIoT y el terminal 810 de CIoT pueden realizar el procedimiento restante.
La división de acuerdo con las características de tráfico de datos usadas por el terminal 810 de CIoT puede ser el contexto de terminal dividido en el tráfico de datos dividido de acuerdo con el fin o características del terminal y puede ser un contexto de terminal dividido de acuerdo con las características de tráfico de datos usadas principalmente por el terminal 810. El contexto de terminal puede estar presente como un identificador como un tipo, el tipo puede representar el tipo del tráfico de datos o el tipo del terminal de CIoT, y el tipo del terminal de CIoT puede significar las características de tráfico de datos. Como alternativa, puede representarse un valor de prioridad que el terminal 810 puede usar. Por ejemplo, el contexto de terminal puede incluir una lista de valores de QCI. El terminal 810 para la seguridad pública usa un valor que corresponde a la prioridad más alta y, por lo tanto, puede transferir el contexto de terminal que incluye el valor que corresponde a la prioridad más alta o el valor de QCI. Además, el terminal 810 que realiza la función de medición puede suscribirse para usar un valor que corresponde a baja prioridad. En este caso, el nodo 830 de CN de CIoT puede incluir el valor de prioridad o el valor de QCI que corresponde al mismo. El terminal 810 que puede transmitir diversas clases de necesidades de tráfico para poder diferenciar prioridad para cada mensaje y, por lo tanto, el nodo 830 de CN de CIoT puede incluir los valores de prioridad o los valores de QCI que pueden usarse por el correspondiente terminal 810.
El nodo 830 de CN de CIoT puede proporcionar diferentes niveles de servicios para cada contexto de terminal a base del contexto de terminal. Por ejemplo, el terminal 810 de IoT de seguridad pública puede autenticarse confirmando que el terminal 810 es para la seguridad pública cuando se conecta a la red y puede procesar el tráfico del correspondiente terminal 81- después de realizar el procedimiento a base de la prioridad. Como otro ejemplo, el terminal 810 para la medición de consumo de gas puede incluir la información sobre las características de tráfico de datos que notifican periódicamente el valor medido a la información de suscripción cuando se conecta a la red y siempre asignan prioridad que corresponde al tráfico de datos de informe periódicos al terminal 810 para la medición de consumo de gas a base de la información. Como otro ejemplo, el usuario puede usar los electrodomésticos que soportan CIoT que configuran la casa inteligente usando la IoT, en más detalle, un aire acondicionado que soporta la función de CIoT para el desencadenador de dispositivo y, por lo tanto, pueden encontrarse las características de tráfico de datos orientado a evento. Además, ya que el desencadenamiento intermedio determina la calidad de servicio, el aire acondicionado necesita procesarse con mayor prioridad que el terminal que tiene las características de datos periódicos, de tal forma que el aire acondicionado puede procesarse con la correspondiente prioridad, incluyendo la información de suscripción que tiene la información sobre las características de tráfico de datos orientado a evento. El procesamiento de prioridades propuesto en la presente invención puede ser prioridad considerada junto con el tráfico de LTE normal y puede ser prioridad considerada entre los tráficos de CIoT.
Además, el valor de prioridad o la lista de los valores de prioridad almacenados en contexto de terminal para el terminal 810 para usar en los datos de IoT pueden transferirse al terminal 810 a través de un procedimiento de estrato sin acceso (NAS) (por ejemplo, conexión, TAU, petición de servicio) del terminal 810.
La Figura 11 es un diagrama que ilustra un procedimiento de asignación de un terminal de CIoT para transmitir un tipo de acuerdo con un modelo de tráfico o el fin / características del terminal de CIoT cuando el terminal de CIoT realiza la petición de servicio/actualización de área de seguimiento/conexión, de acuerdo con una realización.
La Figura 11 ilustra un ejemplo en el que se añade la realización descrita con referencia a la Figura 10. Es decir, en la etapa 1110, puede establecerse una conexión de RRC entre el terminal 810 de CIoT y la C-BS 820. Además, cuando el terminal 810 de CIoT transmite la petición de conexión, la actualización de área de seguimiento, el mensaje de petición de servicio al nodo 830 de CN de CIoT en la etapa 1120, el mensaje puede incluir un identificador que indica la división de acuerdo con las características de tráfico de datos usadas por el terminal 810 de CIoT, un identificador dividido por el tráfico de datos dividido de acuerdo con el fin / características del terminal, o un identificador dividido de acuerdo con las características de tráfico de datos usadas principalmente por el terminal. En este caso, el nodo 830 de CN de CIoT puede mirar al identificador transmitido por el terminal para dividir las características de tráfico de datos usadas por el terminal.
El nodo 830 de CN de CIoT puede autenticar la información sobre el identificador del terminal 810 a base del procedimiento de autenticación del HSS 850 en la etapa 1130 y puede omitir el procedimiento de autenticación de la información sobre el identificador del terminal 810 de acuerdo con la realización de la presente invención.
A continuación, el nodo 830 de CN de CIoT puede almacenar el contexto de terminal que incluye el identificador que puede dividir las características de tráfico en la etapa 1140 y realizan los procedimientos restantes en la etapa 1150. A continuación, el terminal 810 puede mirar al identificador (identificador que puede dividir las características de tráfico de datos) almacenado en el contexto de terminal para proporcionar un servicio que cumple con las características.
Las Figuras 12 a 14 son diagramas de un procedimiento y un procedimiento de aplicación de prioridad cuando el terminal de CIoT y una red de CIoT realizan radiobúsqueda y cuando el terminal de CIoT y la red de CIoT transfieren un paquete, de acuerdo con una realización.
El procedimiento de definición de prioridad puede seguir la política de un operador que opera una red celular. Por ejemplo, puede asignarse prioridad a tráfico que tiene las características de informe de evento, asignarse a tráfico que tiene las características de seguridad pública o emergencia, o asignarse al tráfico para el desencadenante de dispositivo. Como alternativa, la prioridad más baja puede asignarse al terminal 810 de IoT que tiene un modelo de tráfico que transmite los datos periódicos.
De acuerdo con uno descrito con referencia a las Figuras 10 y 11, el procedimiento de aplicación de prioridad ilustrado en las Figuras 12 a 14 puede aplicarse entre el terminal 810 de CIoT y las redes 820, 825, 830, 840 y 850 de la CIoT después de que el nodo 830 de CN de CIoT realiza el procedimiento de almacenamiento de un contexto de terminal.
Haciendo referencia a la Figura 12, el nodo 830 de CN de CIoT determina la prioridad de radiobúsqueda a base del identificador que considera el atributo de tráfico de datos almacenado en el contexto de terminal para transferir una señal de radiobúsqueda procesada a base de prioridad a la C-BS 820.
Describiendo en más detalle, cuando el tráfico para el terminal 810 se genera desde el servidor 840 de aplicación para transmitir radiobúsqueda 1210 para el terminal 810, el nodo 830 de CN de CIoT puede mirar al contexto de terminal para determinar el identificador para las características de tráfico de datos y la prioridad. Además, el nodo 830 de CN de CIoT puede determinar la prioridad de radiobúsqueda a base del identificador y transmitir una señal de radiobúsqueda 1220, que se procesa con prioridad, a la C-BS 820 o al C-eNB 825. La C-BS 820 o el C-eNB 825 puede procesar la señal de radiobúsqueda en el orden en que se solicita la radiobúsqueda para transmitir la señal de radiobúsqueda 1220, que se procesa con prioridad, al terminal 810 de CIoT.
Haciendo referencia a la Figura 13, el nodo 830 de CN de CIoT puede transferir un mensaje de radiobúsqueda 1310 a la C-BS 820, incluyendo el identificador que representa la prioridad en la petición de radiobúsqueda y permitir que la C-BS 820 realice radiobúsqueda del terminal dependiendo de la prioridad incluida en la petición de radiobúsqueda.
Describiendo en más detalle, el nodo 830 de CN de CIoT puede incluir una indicación que representa un nivel de prioridad en el mensaje 1310 de petición de radiobúsqueda transmitido a la C-BS 820 o al C-eNB 825. La C-BS 820 o el C-eNB 825 que recibe el mensaje 1310 de petición de radiobúsqueda puede mirar a la indicación que representa el nivel de prioridad para determinar la prioridad entre diferentes peticiones 1320 de radiobúsqueda. Además, cuando la prioridad del mensaje 1310 de petición de radiobúsqueda recibido está por delante de diferentes peticiones 1320 de radiobúsqueda, la radiobúsqueda puede realizarse primero en el mensaje 1310 de petición de radiobúsqueda recibido. De acuerdo con la realización, la indicación que representa el nivel de prioridad puede representarse dividiendo el nivel de prioridad en diversos niveles y/o puede representan únicamente la prioridad más alta y/o únicamente la prioridad más baja.
Haciendo referencia a la Figura 14, cuando se transmiten unos datos de enlace ascendente / enlace descendente entre el terminal 810 de CIoT y las redes 820, 825, 830, 840 y 850 de CIoT, la prioridad puede aplicarse dependiendo de las características de tráfico.
Describiendo en más detalle, el nodo 830 de CN de CIoT o la C-BS 820 / C-eNB 825 puede transferir un paquete aplicando prioridad a un paquete de enlace ascendente / enlace descendente a base del contexto de terminal que considera las características de tráfico de datos. Además, los terminales 810 y 815 de CIoT pueden realizar una transmisión de enlace ascendente de una indicación que representa las características de tráfico de datos y la prioridad incluyendo la indicación en un encabezamiento de paquete. El presente ejemplo ilustra que el nodo 830 de CN de CIoT incluye la función de P-GW. Sin embargo, cuando la P-GW está presente separándose del nodo 830 de CN de CIoT para establecer el portador de plano de usuario, la P-GW y la S-GW pueden conectarse a la C-BS 820 o al C-eNB 825 para transmitir el paquete al plano de usuario.
De acuerdo con la presente realización, en el caso del enlace descendente, el nodo 830 de CN de CIoT puede recibir un paquete 1410 desde el servidor 840 de aplicación. El nodo 830 de CN de CIoT puede confirmar a cuál de los UE 810 y 815 de CIoT se transfiere el paquete 1410 mirando a una dirección IP de destino de un paquete. Además, el nodo 830 de CN de CIoT puede confirmar el contexto de terminal que coindice con el IP. Si el identificador para las características de tráfico de datos está presente en el contexto de terminal, puede aplicarse la prioridad dependiendo de las correspondientes características de tráfico. Por lo tanto, cuando los paquetes 1420 y 1425 se transfieren a la C-BS 820 o al C-eNB 825, puede aplicarse la prioridad que depende de las características de tráfico de datos para transferir preferencialmente un paquete para un usuario específico o determinar el paquete para el usuario específico como la prioridad más baja y transmitir el mismo. Además, la C-BS 820 o el C-eNB 825 puede transmitir el paquete recibido a los terminales 810 y 815 dependiendo de la prioridad.
En el caso del enlace ascendente, los terminales 810 y 815 de CIoT pueden transmitir paquetes 1430 y 1435 de transmisión al nodo 830 de CN de CIoT como un mensaje de NAS. Como alternativa, los terminales 810 y 815 de CIoT pueden transferir los paquetes 1430 y 1435 a la estación base (C-BS 820 o C-eNB 825) como el mensaje de RRC y la estación base (C-BS 820 o C-eNB 825) también puede transferir los paquetes 1430 y 1435 al nodo 830 de CN de CIoT a través de un mensaje S1. Como alternativa, cuando se establece el plano de usuario, los terminales 810 y 815 de CIoT también pueden transferir los paquetes 1430 y 1435 a través del portador de plano de usuario. El mensaje de NAS indica un mensaje que es transparente para la estación base (C-BS 820 o C-eNB 825) y se transmite y recibe entre los terminales 810 y 815 y el nodo 830 de CN de CIoT. El mensaje S1 indica un mensaje transmitido y recibido entre la estación base (C-BS 820 o C-eNB 825) y el nodo 830 de CN de CIoT.
En los tres procedimientos de acuerdo con la realización detallada, se propone un procedimiento de transferencia, por los terminales 810 y 815 de CIoT, de un paquete de enlace ascendente. Primero, cuando se transmite el paquete de IoT como el mensaje de NAS, los terminales 810 y 815 de CIoT pueden representan las características de tráfico de datos en un punto de código de servicio diferenciado (DSCP) de un encabezamiento del mensaje de NAS o el paquete de IP incluido en el mensaje de NAS como un ejemplo más detallado del DSCP, en el caso del tráfico de datos que transmite el informe de medición, puede establecerse un valor de DSCP que tiene la tolerancia de retardo y la prioridad baja. La indicación de las características de tráfico incluidas en el encabezamiento del mensaje de NAS puede aplicarse al procesamiento de prioridades permitiendo que el nodo 830 de CN de CIoT reciba y confirme el mensaje. En este caso, el nodo 83 de CN de CIoT puede comparar la indicación de las características de tráfico incluidas en el encabezamiento del mensaje de NAS con el contexto de terminal almacenado para determinar si aplicar la prioridad que cumple con las correspondientes características de tráfico. Como alternativa, la prioridad puede aplicarse como la indicación del mensaje transmitido por los terminales 810 y 815. Cuando los terminales 810 y 815 marcan el paquete de IP al DSCP y transmite el paquete de IP marcado, el nodo 830 de CN de CIoT puede realizar la función de P-GW para abrir el paquete de IP y confirmar el DSCP que marca y transmite el mismo al servidor de aplicación aplicando la prioridad basada en el mismo. Como alternativa, los terminales 810 y 815 pueden transferir el mensaje de NAS que incluye el valor de prioridad del paquete de IoT al nodo 830 de CN de CIoT. El mensaje de NAS transmitido desde los terminales 810 y 815 incluye un portador identificador y los datos de IoT y puede incluir adicionalmente el valor de prioridad o el valor de QCI del paquete de IoT. En la anterior descripción, el encabezamiento del mensaje de NAS indica esto. El nodo 830 de CN de CIoT mira al mensaje de NAS transmitido desde los terminales 810 y 815 para comprobar la prioridad para el correspondiente tráfico, realizando de este modo el procesamiento de prioridades.
Segundo, los terminales 810 y 815 pueden transmitir el correspondiente mensaje de RRC a la estación base (C-BS 820 o C-eNB 825), incluyendo la indicación que indica las características de tráfico de datos en el mensaje de RRC junto con el paquete 1435. La indicación que indica las características de tráfico puede ser un valor que representa la prioridad del tráfico o el valor de QCI. Las estaciones 820 y 825 base pueden identificar la indicación que indica las características de tráfico de datos incluidas en el mensaje de RRC y aplica la correspondiente prioridad para transmitir el mismo al nodo 830 de CN de CIoT. La estación base (CBS 820 o C-eNB 825) configura el paquete recibido desde el terminal como el mensaje S1 y transmite el paquete al nodo de CN de CIoT. En este caso, la estación base puede transferir el mensaje S1 que incluye una indicación que corresponde a la indicación que indica las características de tráfico de datos recibidas desde los terminales 810 y 815. El nodo de CN de CIoT que recibe el mensaje S1 puede aplicar la prioridad mirando a la indicación incluida en el mensaje S1 para transmitir el paquete al servidor 840 de aplicación o la P-GW. La indicación que indica las características de tráfico pueden significar el valor que representa la prioridad del tráfico a transmitirse desde los terminales 810 y 815 o el valor de QCI.
A continuación, se describirá un procedimiento de asignación de prioridad a tráfico de servicio de multidifusión de difusión multimedia (MBMS) en una retransmisión de equipo de usuario-red (UE-red) de servicio basado en proximidad (ProSe).
De acuerdo con una realización en un procedimiento de provisión de un servicio de retransmisión para tráfico de MBMS a través de la retransmisión de UE-red (NW) de ProSe, un valor de prioridad por paquete (PPP) de ProSe a aplicarse cuando un paquete se transmite puede establecerse en la retransmisión de UE-NW de ProSe.
La Figura 15 es un diagrama que ilustra un ejemplo de una estructura de red de ProSe.
Haciendo referencia a la Figura 15, mediante el servicio de proximidad entre el terminal, puede recibirse un servicio a través de una red usando un retransmisor 1520 de UE-NW de ProSe.
El UE 1520 de retransmisión de UE-NW (o UE de retransmisión) sirve como un retransmisor que transfiere un servicio proporcionado desde una red celular 1590 al UE 1510 remoto, mientras está dentro de la cobertura de la estación 1530 base (eNB). Mientras tanto, la red celular 1590 puede incluir una estación 1530 base, una función 1540 de ProSe, una MME 1550, una pasarela (GW) 1560, un HSS 1570, una BMSC 1575 o similar.
Mientras tanto, el UE 1520 de retransmisión de UE-NW puede recibir diversas clases de información para registrar que el UE 1520 de retransmisión de UE-NW es un retransmisor y proporcionar un servicio de retransmisión a través de la red de EPS 1590 o puede preparar un servicio de retransmisión tal como una generación de una conexión de PDN para proporcionar un servicio de IP al UE 1510 remoto. Además, cuando se prepara el servicio de retransmisión, el UE 1520 de retransmisión de UE-NW difunde un mensaje de anuncio para notificar directamente que el UE 1520 de retransmisión de UE-NW es un retransmisor de acuerdo con un procedimiento de descubrimiento, de tal forma que el UE 1510 remoto puede descubrir el UE 1520 de retransmisión de UE-NW. Como alternativa, el UE 1520 de retransmisión de UE-NW recibe un mensaje de solicitud de descubrimiento transmitido cuando un UE 1510 remoto alrededor del mismo encuentra un retransmisor, y si cumple con la correspondiente condición, el UE 1520 de retransmisión de UE-NW transmite un mensaje de respuesta de descubrimiento y, por lo tanto, el UE 1510 remoto también puede descubrir el UE 1520 de retransmisión de UE-NW. El UE 1510 remoto puede seleccionar el retransmisor deseado entre los UE 1520 de retransmisión de UE-NW descubiertos para establecer la conexión entre el correspondiente UE 1520 de retransmisión de UE-NW y el UE 1510 remoto, de tal forma que el UE 1510 remoto puede recibir un servicio a través de la red celular 1590.
En este caso, el valor de prioridad por paquete de ProSe a aplicarse cuando el tráfico de MBMS se transmite puede establecerse en el UE 1520 de retransmisión de UE-NW de ProSe.
La Figura 16 es un diagrama de flujo que ilustra un procedimiento de recepción de un valor de Prioridad por Paquete de ProSe de acuerdo con una realización.
Haciendo referencia a la Figura 16, de acuerdo con la realización, el UE 1520 de retransmisión puede asignarse con un valor de PPP por defecto en una etapa de provisión.
El UE 1520 de retransmisión de UE-NW de ProSe puede realizar un procedimiento de preparación de un servicio de retransmisión a través de un procedimiento de autorización de servicio. En la etapa 1610, el UE 1510 remoto de ProSe puede transmitir un mensaje de petición de autorización de servicio a la función 1540 de ProSe para el procedimiento de autorización de servicio. Además, en la etapa 1630, la función 1540 de ProSe puede transmitir el mensaje de respuesta de autorización de servicio al UE 1510 remoto. De acuerdo con la realización la función 1540 de ProSe puede recibir la información sobre el servicio de ProSe para el UE 1510 remoto desde e1HSS 1570 un mensaje de petición de SH y un mensaje de respuesta de SH de las etapas 1620 y 1630, si es necesario.
Mientras tanto, el retransmisor 1520 de UE-NW que puede proporcionar el servicio de retransmisión o proporciona el servicio de retransmisión puede proporcionar el servicio de retransmisión o también puede transmitir la indicación de retransmisión para indicar el terminal que proporciona el servicio de retransmisión cuando el mensaje de petición de autorización de servicio se transmite a la función 1540 de ProSe en la etapa 1640. En este caso, la función 1540 de ProSe puede confirmar si el terminal 1520 que transmite el mensaje de petición de autorización de servicio en la etapa 1640 es un terminal que proporciona el servicio de retransmisión a base de su propia información. Como alternativa, la función 1540 de ProSe puede transmitir un mensaje (por ejemplo, petición de SH) que consulta si el terminal 1520 que transmite el mensaje de petición de autorización de servicio en la etapa 1640 a1HSS 1570 es un terminal que proporciona el servicio de retransmisión en la etapa 1650 y recibe y confirma el mensaje de respuesta (por ejemplo, respuesta de SH) al mismo desde el HSS 1570 en la etapa 1655. En este caso, en la etapa 1655, e1HSS 1570 puede transmitir el mensaje de respuesta de SH que incluye la indicación de retransmisión.
Además, la función 1540 de ProSe puede transferir el valor de PPP por defecto a usarse cuando el UE 1520 de retransmisión de UE-NW proporciona el servicio de retransmisión para el tráfico de MBMS al UE 1520 de retransmisión a través del mensaje de respuesta de autorización de servicio en la etapa 1660, dependiendo del valor almacenado en la función 1540 de ProSe o el valor incluido en el mensaje recibido desde e1HSS 240 en la etapa 1655. De acuerdo con la realización el valor de PPP por defecto puede asignarse al UE 1520 de retransmisión a través de un servidor de aplicación de terceros, además de la función 1540 de ProSe o el HSS 1570.
Mientras tanto, en la etapa 1670, el UE 1510 remoto notifica al UE 1520 de retransmisión la información de TMGI deseada cuando se recibe el tráfico de MBMS para solicitar la supervisión del tráfico de MBMS para el correspondiente TMGI. Además, el UE 1520 de transmisión solicitado transfiere ID de tráfico de grupo L2 de ProSe que indica un grupo de ProSe a usarse para transmitir el tráfico de MBMS que corresponde al TMGI al UE 1510 remoto como una respuesta a la petición. Además, en la etapa 1680, el UE 1520 de retransmisión puede recibir el tráfico de MBMS para el TMGI. En este caso, el UE 1520 de retransmisión difunde el correspondiente tráfico de MBMS al ID de tráfico de grupo L2 de ProSe a través de una interfaz PC5 dependiendo del valor de PPP por defecto asignado a partir de la función 1540 de ProSe en la etapa 1690.
De acuerdo con otra realización cuando se difunde el tráfico de MBMS al ID de tráfico de grupo L2 de ProSe, el UE 1520 de retransmisión se refiere al valor de PPP por defecto y el número de UE 1510 remotos que solicitan el terminal que solicita al UE de retransmisión para definir el valor de prioridad por paquete (PPP), transmitiendo de este modo el tráfico. Por ejemplo, cuando el valor de PPP por defecto es 3 y el terminal que solicita el terminal que solicita es uno, el valor de PPP se establece para ser 3, mientras cuando el terminal que solicita la supervisión de TMGI es igual a o más de 5, un valor de PPP mayor puede establecerse para ser 2 para transmitir tráfico.
La Figura 17 es un diagrama de flujo que ilustra un procedimiento de recepción de información de PPP a través de un terminal remoto.
Haciendo referencia a la Figura 17, de acuerdo con la realización, de la presente invención, el UE 1520 de retransmisión puede recibir la información de prioridad por paquete (PPP) de ProSe a través del UE 1510 remoto.
El UE 1510 remoto accede al UE 1520 de retransmisión de UE-NW y, a continuación, en la etapa 1710, puede solicitar la supervisión de TMGI para transmitir el mensaje de petición de supervisión de TMGI para solicitar la transmisión de tráfico de MBMS que corresponde a un TMGI específico al UE 1520 de retransmisión. En este caso, el mensaje de petición de supervisión de TMGI transfiere el TMGI e identidades de área de servicio de MBMS (SAI) y la información relacionada con prioridad por paquete (PPP) sobre el tráfico de MBMS adquirido desde una capa de aplicación del propio UE 1510 remoto al UE 1520 de retransmisión. Es decir, el UE 1510 remoto puede transmitir información sobre prioridad que quiere el UE 1510 remoto para recibir al UE 1520 de retransmisión.
Describiendo en más detalle, la capa de aplicación del UE 1510 remoto puede determinar la información relacionada con PPP de ProSe. En este caso, la capa de aplicación del UE 1510 remoto puede determinar la información relacionada con PPP asociada con el TMCI especifico que el UE 1510 remoto solicita. Además, la capa de aplicación, que es una capa superior del UE 1510 remoto, puede transmitir la información relacionada con PPP determinada a la capa de ProSe. Por consiguiente, la capa de ProSe del UE 1510 remoto puede transmitir el valor de PPP, que se recibe desde la capa de aplicación e incluye en el mensaje de petición de supervisión de TMGI, al UE 1520 de retransmisión.
Como la información relacionada con PPP, el valor de PPP asignado desde la capa de aplicación del UE 1510 remoto, puede usarse un tipo de llamada (por ejemplo, información o similar de emergencia / peligro inminente /normal) para el correspondiente servicio o similar.
El UE 1520 de retransmisión determina el valor de PPP a usarse realmente a base de la información. Cuando el UE 1520 de retransmisión tiene el valor de PPP existente para el correspondiente TMGI, el UE 1520 de retransmisión ignora el valor de PPP existente y puede sustituir el valor de PPP existente en un nuevo valor de PPP. Como alternativa, puede ser posible el caso en el que el UE 1520 de retransmisión descarta el nuevo valor de PPP y usa continuamente el valor de PPP existente.
Además, en la etapa 1720, el UE 1520 de retransmisión puede transmitir el mensaje de respuesta de supervisión de TMGI al UE 1510 remoto. En este caso, el UE 1520 de retransmisión también puede transmitir el ID de tráfico de grupo L2 que es la información de grupo de ProSe asignada y, de acuerdo con la realización, de la presente invención, también puede transmitir el valor de PPP a usarse al UE 1510 remoto incluyendo el valor de PPP en el mensaje de respuesta de supervisión de TMGI. De acuerdo con la realización de la presente invención, el valor de PPP a usarse no se incluye en el mensaje de respuesta de supervisión de TMGI y puede referenciarse únicamente tras la transmisión del tráfico de MBMS posteriormente.
Además, si el UE 1520 de retransmisión recibe el tráfico de MBMS en la etapa 1730, en la etapa 1740, el UE 1520 de retransmisión retransmite el tráfico de MBMS recibido a transmitirse a una interfaz PC5 usando el valor de PPP.
A continuación, se describirá un procedimiento de provisión de QoS en una red de EPS para tráfico transmitido a través de un retransmisor de UE-red de ProSe.
De acuerdo con la realización de la presente invención, el portador de EPS puede modificarse o el portador de EPS puede generarse para proporcionar una QoS apropiada en una red de EPS al UE remoto que recibe un servicio de red de EPS a través de la retransmisión de UE-NW de ProSe puede proporcionarse.
La Figura 18 es un diagrama que ilustra un ejemplo de una estructura de red de ProSe y una estructura de red de IMS y EPS.
Haciendo referencia a la Figura 18, por el servicio de proximidad entre los terminales, puede recibirse un servicio de IMS a través de la red de EPS usando el retransmisor 1520 de UE-NW de ProSe.
Si el UE 1520 de retransmisión de UE-NW de ProSe está dentro de la cobertura de la estación base eNB 1530, el UE 1520 de retransmisión de UE-NW de ProSe sirve como la función de retransmisión de transferencia del servicio proporcionado desde la red celular 1590 al UE 1510 remoto. Mientras tanto, la red celular 1590 puede incluir la estación 1530 base, la función 1540 de ProSe, la MME 1550, la pasarela (GW) 1560, e1HSS 1570, la PCRF 1580 o similar. Además, una red 1810 de IMS puede incluir una P-CSc F 1820, una S-CSCF 1830, un AS 1840 de MCPTT o similar.
Mientras tanto, el UE 1520 de retransmisión de UE-NW puede recibir diversas clases de información para registrar que el UE 1520 de retransmisión de UE-NW es el retransmisor y proporcionar el servicio de retransmisión a través de la red de EPS 1590 o puede preparar el servicio de retransmisión tal como la generación de la conexión de PDN para proporcionar el servicio de IP al Ue 1510 remoto. Además, cuando se prepara el servicio de retransmisión, el UE 1520 de retransmisión de UE-NW difunde el mensaje de anuncio para notificar directamente que el UE 1520 de retransmisión de UE-NW es el retransmisor de acuerdo con el procedimiento de descubrimiento, de tal forma que el UE 1510 remoto puede descubrir el UE 1520 de retransmisión de UE-NW. Como alternativa, el UE 1520 de retransmisión de UE-NW recibe el mensaje de solicitud de descubrimiento transmitido cuando el UE 1510 remoto alrededor del mismo encuentra el retransmisor, y si cumple con la correspondiente condición, el UE 1520 de retransmisión de UE-NW transmite el mensaje de respuesta de descubrimiento y, por lo tanto, el UE 1510 remoto también puede descubrir el UE 1520 de retransmisión de UE-NW. El UE 1510 remoto puede seleccionar el retransmisor deseado entre los UE 1520 de retransmisión de UE-NW descubiertos para establecer la conexión entre el correspondiente UE 1520 de retransmisión de UE-NW y el UE 1510 remoto, de tal forma que el UE 1510 remoto puede recibir un servicio a través de la red.
El UE 1510 remoto puede recibir los servicios de MCPTT tales como comunicación por voz y comunicación de imágenes a través de la red 1810 de IMS mediante la conexión. Por cierto, la asignación de recursos al UE 1520 de retransmisión en la red de EPS 1590 se hace entre la GW 1560 y el UE 1520 de retransmisión y el UE 1510 remoto recibe un servicio que usa los recursos. Por lo tanto, se requiere un procedimiento de provisión de una QoS apropiada entre una GW y un UE 1520 de retransmisión.
Por lo tanto, para proporcionar la QoS apropiada dentro de la red de EPS 1590 al UE 1510 remoto que recibe el servicio de red de e Ps 1590 a través del retransmisor 1520 de UE-NW de ProSe, se describirá en detalle un procedimiento de modificación o generación de un portador de EPS.
La Figura 19 es un diagrama de flujo de asignación de una QoS apropiada a un portador de EPS para una retransmisión a través de una PCRF.
Haciendo referencia a la Figura 19, de acuerdo con la realización, la QoS apropiada puede asignarse al portador de EPS para el fin del retransmisor a través de la PCRF 1580.
Para el servicio de IMS, el UE 1510 remoto puede transmitir el mensaje de SIP a la P-CSCF 1820 en la etapa 1910. En este caso, el UE 1510 remoto establece un tipo de acceso de un campo de encabezamiento de Información de Red de Acceso P de un encabezamiento de SIP como Retransmisor ProSe de EUTRAN de 3GPP o UNR ProSe de EUTRAN de 3GPP para notificar a la P-CSCF 1820 que accede a la red de IMS a través de la retransmisión de ProSe. Por supuesto, el procedimiento de notificación de la situación de acceso a la red de IMS a través de la retransmisión de ProSe también puede notificar el acceso a través del Retransmisor de ProSe usando un campo separado además del tipo de acceso. El mensaje de SIP transmitido desde el UE 1510 remoto incluye registro de SIP, invitación de SIP, actualización de SIP, SIP 2000K, etc.
En este punto, por conveniencia de explicación, el mensaje de invitación de SIP se describirá como un ejemplo.
En la etapa 1910, si la P-CSCF 1820 que recibe la INVITACIÓN de SIP reconoce el acceso a través de la retransmisión de ProSe, la P-CSCF 1820 puede rastrear y encontrar la PCRF 1580 que asigna una regla de PCC desde la dirección IP de origen del paquete de IP recibir la invitación de SIP al UE 1520 de retransmisión. Además, la P-CSCF 1820 puede transmitir una petición de AA a la PCRF 1580 encontrada en la etapa 1930 para transmitir información sobre características de un flujo de llamada a base de un SDP transferido junto con el mensaje de SIP. En este caso, la petición de AA incluye la dirección IP del UE 1520 de retransmisión encontrado desde la dirección IP de origen en lugar de un valor de ID de suscripción y un campo que notifica que la petición de AA es un terminal a través de la retransmisión de ProSe puede insertarse. En la etapa 1935, la PCRf 1580 recibir la petición de AA rastrea y encuentra el valor de IMSI del UE 1520 de retransmisión a base de la correspondiente dirección IP. En este caso, de acuerdo con la realización, la PCRF 1580 también puede interfuncionar con la PGW 1560 para rastrear un valor de IMSI del UE 1520 de retransmisión.
Como la respuesta a la misma, la PCRF 1580 puede transferir la respuesta de AA a la P-CSCF 1820 en la etapa 1937. Además, la PCRF 1580 puede generar la regla de PCC de acuerdo con las características del flujo de llamada obtenido a partir de la petición de AA y transferir la regla de PCC generada a la PGW 1560. Además, cuando la PGW 1560 cambia la QoS asignada al portador de EPS existente de acuerdo con la regla de PCC, en la etapa 1940, la PGW 1560 puede transmitir la petición de actualizar portador a la MME 1550. Además, cuando la PGW 1560 genera el portador de EPS separado de acuerdo con la regla de PCC, en la etapa 1940, la PGW 1560 puede transmitir la petición de crear portador a la MME 1550. Como resultado, la MME 1550 puede realizar un procedimiento de modificación de contexto de portador de EPS o procedimiento de activación de contexto de portador de EPS especializado junto con el UE 1520 de retransmisión en las etapas 1950 y 1960. Además, la MME 1550 puede transferir la respuesta de actualizar portador o mensaje de respuesta de crear portador como la respuesta a la misma a la PGW 1560 en la etapa 1970. En consecuencia, el UE 1510 remoto transmite datos transmitidos y recibidos a y desde el UE 1520 de retransmisión y el ProSe a través de la red de EPS usando el portador de EPS modificado o generado en la etapa 1980.
De acuerdo con otra realización si la P-CSCF 1820 que recibe el mensaje de INVITACIÓN de SIP reconoce el acceso a través de la retransmisión de ProSe en la etapa 1910, la P-CSCF 1820 reconoce que es imposible generar la regla de PCC para proporcionar las características del flujo de llamada propuesto en el s Dp incluido en el mensaje de SIP a través de la petición de AA y, por lo tanto, también puede operarse para no realizar el procedimiento de petición de AA en absoluto. En este caso, la PCRF 1580 puede no realizar la modificación de portador de EPS o la activación de portador de EPS que se desencadena.
La Figura 20 es un diagrama que ilustra un procedimiento de permitir que un terminal remoto solicite una QoS apropiada a un portador de EPS para una retransmisión y asignación de la QoS al terminal remoto.
Haciendo referencia a la Figura 20, de acuerdo con la realización, el UE 1510 remoto puede solicitar directamente la QoS apropiada al portador de EPS para el fin del retransmisor y puede asignarse con la QoS solicitada.
Cuando se transmite el mensaje de SIP para el servicio de IMS, el UE 1510 remoto establece el tipo de acceso del campo de encabezamiento de Información de Red de Acceso P del encabezamiento de SIP as el Retransmisor de ProSe de EUTRAN 3GPP o el eUNR de ProSe de EUTRAN 3GPP para notificar el estado en el que el UE 1510 remoto accede a la red de IMS a través de la retransmisión de ProSe y reconoce que es imposible modificar y generar el portador de EPS a través de la PCRF 1580 como la respuesta al mismo o establece de forma idéntica el tipo de acceso con el acceso normal como la FDD de EUTRAN 3GPP o la TDD de EUTRAN 3GPP sin notificar que es el acceso de IMS a través de la retransmisión de ProSe usando el mensaje de SIP, pero cuando se conoce por adelantado el hecho de que es imposible modificar y generar el portador de EPS a través de la PCRF 1580, puede realizar el procedimiento para recibir la asignación de la QoS apropiada como la presente invención.
Cuando el UE 1510 remoto genera o finaliza la llamada IMS, en la etapa 2020, el UE 1510 remoto puede transferir un mensaje de petición de asignación de recursos o un mensaje de petición de modificación de recursos al UE 1520 de retransmisión a través de la interfaz PC5. El mensaje puede incluir características del flujo de llamada para añadirse o cambiase nuevamente.
En la etapa 2020, el UE 1520 de retransmisión que recibe el mensaje puede transmitir un mensaje de petición de asignación de recursos de portador solicitado por UE o un mensaje de petición de modificación de recursos de portador solicitado por UE a la MME 1550 en la etapa 2030. De este modo, el UE 1520 de retransmisión puede solicitar el cambio de la QoS a través de la modificación de portador de EPS o solicitar la generación de portador de EPS de la nueva QoS.
Por lo tanto, la MME 1550 puede transmitir un comando de petición de portador a la PGW 1560 en la etapa 2040. Por lo tanto, cuando la PGW 1560 cambia la QoS asignada al portador de EPS existente o genera el portador de EPS separado de acuerdo con la regla de PCC, en la etapa 2045, la PGW 1560 puede transmitir la petición de actualizar portador o la petición de crear portador a la MME 1550. Además, la MME 1550 puede realizar un procedimiento de modificación de contexto de portador de EPS o procedimiento de activación de contexto de portador de EPS especializado junto con el UE 1520 de retransmisión en la etapa 2050. Además, la MME 1550 puede transferir la respuesta de actualizar portador o mensaje de respuesta de crear portador como la respuesta a la misma a la PGW 1560 en la etapa 2080. La modificación o generación del portador de EPS se describirá en detalle con referencia a la porción asociada con la Figura 19.
Además, el UE 1520 de retransmisión puede transferir un resultado de generación al UE 1510 remoto a través de la interfaz PC5 usando la respuesta de modificación de recursos o mensaje de respuesta de asignación de recurso en la etapa 2070. En consecuencia, el UE 1510 remoto transmite datos transmitidos y recibidos a y desde el UE 1520 de retransmisión y el ProSe a través de la red de EPS usando el portador de EPS modificado o generado en la etapa 2090.
Mientras tanto, cuando se libera el acceso entre el UE 1510 remoto y el UE 1520 de retransmisión, el UE 1520 de retransmisión solicita la modificación de portador de petición de UE o transmite la petición de desactivación de portador de petición de UE a la MME 1550 como en la etapa 2030 para modificar o borrar el portador de EPS, operando de este modo de forma efectiva el recurso.
Como otra realización en la Figura 20, el UE 1510 remoto puede no realizar directamente la modificación de recursos o la asignación de recursos como en la etapa 2020. Además, considerando el número de UE 1520 de retransmisión que accede al UE 1520 de retransmisión y la capacidad del tráfico de uso, el UE 1520 de retransmisión puede transmitir el mensaje de petición de asignación de recursos de portador solicitado por UE o el mensaje de petición de modificación de recursos de portador solicitado por UE a la MME 1550 en la etapa 2030 para solicitar el cambio de la QoS o la generación del portador de EPS de la nueva QoS a través de la modificación de portador de EPS. Por lo tanto, el portador de EPS se modifica o genera mediante el procedimiento como en la Figura 20 y, a continuación, como en la etapa 2090, los datos transmitidos y recibidos entre el UE 1510 remoto y el UE 1520 de retransmisión usando el ProSe se transmiten a través del portador de EPS modificado o generado mediante el procedimiento en la red de EPS.
Mientras tanto, cuando se libera el acceso entre el UE 1510 remoto y el UE 1520 de retransmisión o se reduce el tráfico de uso durante un tiempo predeterminado, el UE 1520 de retransmisión solicita la modificación de portador de petición de UE o transmite la petición de desactivación de portador de petición de UE a la MME 1550 como en la etapa 2030 para modificar o borrar el portador de EPS, operando de este modo de forma efectiva el recurso.
A continuación, se describirá un procedimiento de transferencia de información posicional en una red de IMS a través de un retransmisor de UE-red de ProSe.
De acuerdo con la realización para adquirir el código de área de seguimiento (TAC) y el identificador de célula (ECI) de EUTRAN incluido en el campo de encabezamiento de Información de Red de Acceso P del encabezamiento de mensaje de SIP, el UE remoto que accede a la red de IMS a través del retransmisor de UE-red de ProSe adquiere la información pertinente a través del UE de retransmisión o procesa el valor de TAC o ECI como un valor sin sentido introduce para proporcionar normalmente el servicio de IMS.
Haciendo referencia a la Figura 18, el UE 1510 remoto puede recibir los servicios de MCPTT tal como la comunicación por voz y la comunicación de imagen a través de la red 1810 de IMS. Por cierto, cuando se accede a la red 1810 de IMS a través de la red de EPS 1590, el campo de encabezamiento de Información de Red de Acceso P del encabezamiento de SIP puede incluir la información posicional, es decir, la información de MCC y MNC, la información de código de área de seguimiento (TAC) y la información de ID de célula de EUTRAN (ECI) o similar.
Sin embargo, el UE 1510 remoto no accede directamente al eNB 1530 sino que accede a la red a través del UE de retransmisión, eliminando de este modo la información de TAC y la información de ECI. Por lo tanto, para recibir normalmente el servicio de IMS, se requiere un procedimiento para adquirir información de TAC e información de ECI.
La Figura 21 es un diagrama de flujo de provisión de un valor ficticio para TAC y ECI a un encabezamiento de SIP.
Haciendo referencia a la Figura 21, de acuerdo con la realización, el UE 1510 remoto puede proporcionar un valor ficticio para el TAC y el ECI al encabezamiento de SIP.
Cuando el UE 1510 remoto transmite el mensaje de SIP a la P-CSCF 1820 / S-CSCF 1830 para el servicio de IMS en la etapa 2110, el UE 1510 remoto establece el tipo de acceso del campo de encabezamiento de Información de Red de Acceso P del encabezamiento de SIP como el Retransmisor de ProSe de EUTRAN 3GPP o el UNR de ProSe de EUTRA 3GPP para notificar a la P-CSCF 1820 que accede a la red de IMS a través de la retransmisión de ProSe. Por ejemplo, puede ponerse en el campo de encabezamiento del encabezamiento de SIP como se indica a continuación.
Información de Red de Acceso P: Retransmisión de ProSe de EUTRAN de 3GPP;id de célula de EUTRAN 3gpp=11122233C476B4321;proporcionado por red o
Información de Red de Acceso P: UNR de ProSe de EUTRAN de 3GPP;id de célula de EUTRAN 3gpp=11122233C476B4321;proporcionado por red.
Los primeros seis dígitos 111222 representan información de PLMN, los siguientes cuatro dígitos 33C4 representan información de TAC y los siguientes siete dígitos 76B4321 representan información de ECI.
Por supuesto, el procedimiento de notificación de un acceso a una red de IMS a través de una retransmisión de ProSe también puede notificar el acceso a través de la retransmisión de ProSe usando el campo separado además del tipo de acceso. El mensaje de SIP transferido desde el UE 1510 remoto incluye registro de SIP, invitación de SIP, actualización de SIP, S iP 2000K, etc.
En este punto, por conveniencia de explicación, el mensaje de registro de SIP se describirá como un ejemplo.
En este caso, si las entidades de IMS tal como la P-CSCF 1820 o la S-CSCF 1830 que reciben el mensaje de registro de SIP reconocen el acceso a través de la retransmisión de ProSe a partir de la información de encabezamiento, las entidades de IMS pueden considerar el valor de información de TAC (33C4 en el dibujo) y el valor de información de ECI (76B4321 en el dibujo) incluidos en el campo de encabezamiento de Información de Red de Acceso P como un valor ficticio e ignorar el valor relacionado.
La Figura 22 es otro diagrama de flujo de provisión del valor ficticio para el TAC y el ECI al encabezamiento de SIP.
Haciendo referencia a la Figura 22, de acuerdo con la realización, el UE 1510 remoto puede proporcionar el valor ficticio para el TAC y el ECI al encabezamiento de SIP.
Cuando el UE 1510 remoto transmite el mensaje de SIP a la P-CSCF 1820 / S-CSCF 1830 para el servicio de IMS en la etapa 2210, el UE 1510 remoto establece el tipo de acceso del campo de encabezamiento de Información de Red de Acceso P del encabezamiento de SIP como un TDD de EUTRa N de 3GPP o un FDD de EUTRAN de 3GPP mediante el mismo procedimiento como el mensaje de SIP a través de la red de EPS general. Sin embargo, puede notificarse que se usa el valor ficticio, usando el valor de TAC predefinido o valor de ECI predefinido empleado anteriormente entre el proveedor y el terminal. Por ejemplo, el t Ac predefinido = FFF y el ECl predefinido pueden ponerse en el campo de encabezamiento como se indica a continuación.
Cuando el UE 1510 remoto no conoce únicamente el valor de TAC, el campo de encabezamiento puede ser como se indica a continuación.
Información de Red de Acceso P: FDD de EUTRAN de 3GPP;id de célula de EUTRAN 3gpp=111222FFFF76B4321;proporcionado por red.
Cuando el UE 1510 remoto no conoce ni el valor de TAC ni el valor de ECl, el campo de encabezamiento puede ser como se indica a continuación.
Información de Red de Acceso P: FDD de EUTRAN de 3GPP;id de célula de EUTRAN 3gpp=111222FFFFFFFFFFF;proporcionado por red.
El mensaje de SIP transmitido desde el UE 1510 remoto incluye registro de SIP, invitación de SIP, actualización de SIP, SIP 2000K, etc.
En este punto, por conveniencia de explicación, el mensaje de registro de SIP se describirá como un ejemplo.
Si las entidades de IMS tal como la P-CSCF 1820 o la S-CSCF 1830 que reciben el mensaje de registro de SIP reconocen a partir de la información de encabezamiento que se usa el valor ficticio en la etapa 2220, el correspondiente valor de TAC y ECl incluido en el campo de encabezamiento de Información de Red de Acceso P puede ignorarse.
La Figura 23 es un diagrama de flujo que ilustra un ejemplo de un procedimiento de permitir que un UE remoto solicite un UE de retransmisión para adquirir valores de ECGl y TAC.
Haciendo referencia a la Figura 23, de acuerdo con la realización, el UE 1510 remoto puede solicitar el UE 1520 de retransmisión adquiera los valores de ECGl y TAC.
En la etapa 2310, el UE 1510 remoto puede transmitir una célula ID mensaje de anuncio de petición al UE 1520 de retransmisión para solicitar la información de célula. En la etapa 2320, el UE 1520 de retransmisión puede transmitir un actualizar temporizador al UE 1510 remoto junto con la respuesta de anuncio de ID de célula. Además, en la etapa 2330, cuando el correspondiente actualizar temporizador expira, el UE 1520 de retransmisión puede difundir el anuncio de ID de célula. El mensaje de anuncio de ID de célula incluye la información de ECGl así como la información de TAC de la célula a la que accede el UE 1520 de retransmisión. Por lo tanto, el UE 1510 remoto que recibe el mensaje de anuncio de ID de célula puede adquirir la información de PLMN y la información de ECl a partir de la información de ECGl del UE de retransmisión recibida desde el UE 1520 de retransmisión y usar la información de TAC del UE 1520 de retransmisión recibida simultáneamente con la misma para reflejar la misma al encabezamiento de mensaje de SIP. Por ejemplo, puede ponerse en el campo de encabezamiento como se indica a continuación.
Información de Red de Acceso P: FDD de EUTRAN de 3GPP;id de célula de EUTRAN 3gpp=1 1122233C476B4321;proporcionado por red.
Los primeros seis dígitos 111222 representan información de PLMN, los siguientes cuatro dígitos 33C4 representan información de TAC y los siguientes siete dígitos 76B4321 representan información de ECI. Además, en la etapa 2340, el UE 1510 remoto puede transmitir el mensaje de SIP a las entidades de IMS tales como la P-CSCF 1820 o la S-CSCF 1830.
La Figura 24 es un diagrama de flujo que ilustra otro ejemplo del procedimiento de permitir que un UE remoto solicite un UE de retransmisión para adquirir valores de ECGI y TAC.
Haciendo referencia a la Figura 24, de acuerdo con la realización, el UE 1510 remoto puede solicitar el UE 1520 de retransmisión adquiera los valores de ECGI y TAC.
En la etapa 2410, el UE 1510 remoto puede transmitir el mensaje de anuncio de ID de célula de petición al UE 1520 de retransmisión para solicitar la información de célula siempre que transmite el mensaje de SIP. Además, en la etapa 2420, el UE 1520 de retransmisión puede transmitir la respuesta de información de célula que incluye el ECGI e información de TAC del UE de retransmisión 1510.
Por lo tanto, el UE 1510 remoto que recibe la respuesta de información de célula puede adquirir la información de PLMN y la información de ECI a partir de la información de ECGI del UE de retransmisión recibida desde el UE 1520 de retransmisión y usar la información de TAC del UE 1520 de retransmisión recibida simultáneamente con las mismas para reflejar la misma al encabezamiento de mensaje de SIP. Por ejemplo, puede ponerse en el campo de encabezamiento como se indica a continuación.
Información de Red de Acceso P: FDD de EUTRAN de 3GPP;id de célula de EUTRAN 3gpp=1 1122233C476B4321;proporcionado por red.
Los primeros seis dígitos 111222 representan información de PLMN, los siguientes cuatro dígitos 33C4 representan información de TAC y los siguientes siete dígitos 76B4321 representan información de ECI. Además, en la etapa 2430, el UE 1510 remoto puede transmitir el mensaje de SIP a las entidades de IMS tales como la P-CSCF 1820 o la S-CSCF 1830.
La Figura 25 es un diagrama de configuración en bloques de un terminal de acuerdo con una realización.
Haciendo referencia a la Figura 25, el terminal de acuerdo con una realización puede incluir un transceptor 2510 y un controlador 2520 que controla la operación general del terminal. En este caso, el terminal puede significar uno cualquiera de un terminal de MCPTT, un terminal de CIoT, un terminal de LTE y CIoT, un terminal remoto y un terminal de retransmisión.
El controlador 2520 del terminal controla el terminal para realizar una operación cualquiera de las realizaciones anteriores. Por ejemplo, cuando el terminal es el terminal remoto, el controlador 2520 del terminal puede realizar un control para transmitir el mensaje de petición de supervisión de TMGI que incluye la prioridad por paquete de ProSe al terminal de retransmisión y recibir el tráfico de MBMS desde el terminal de retransmisión dependiendo de la prioridad por paquete de ProSe. Como alternativa, cuando el terminal es el terminal de retransmisión, el controlador 2520 del terminal puede realizar un control para recibir el mensaje de petición de supervisión de TMGI que incluye la prioridad por paquete de ProSe desde el terminal remoto y transmitir el tráfico de MBMS al terminal remoto dependiendo de la prioridad por paquete de ProSe.
Además, el transceptor 2510 del terminal puede transmitir y recibir una señal de acuerdo con una operación cualquiera de las realizaciones anteriores. Por ejemplo, cuando el terminal es el terminal remoto, el transceptor 2510 del terminal puede transmitir el mensaje de petición de supervisión de TMGI que incluye la prioridad por paquete de ProSe al terminal de retransmisión y recibir el tráfico de MBMS. Además, cuando el terminal es el terminal de retransmisión, el transceptor 2510 del terminal puede recibir el mensaje de petición de supervisión de TMGI que incluye la prioridad por paquete de ProSe desde el terminal remoto y transmitir el tráfico de MBMS.
La Figura 26 es un diagrama de configuración en bloques de entidad de red de acuerdo con una realización.
Haciendo referencia a la Figura 25, la entidad de red de acuerdo con una realización puede incluir un transceptor 2610 y un controlador 2620 que controlan la operación general del terminal. En este caso, siempre que la entidad de red es entidades de red para describir la realización tales como la estación base, la MME, la función de ProSe, el servidor de aplicación de MCPTT, la P-CSCF, el HSS, la GW, el MSSC y la MCE, cualquier entidad de red puede corresponder a las mismas.
El controlador 2620 de la entidad de red controla la entidad de red para realizar una operación cualquiera de las realizaciones anteriores. Por ejemplo, cuando la entidad de red es el AS de GCS, el controlador 2620 de la entidad de red puede realizar un control para recibir la lista de ECGI desde el terminal. Como alternativa, cuando la entidad de red es la función de ProSe, el controlador 2620 de la entidad de red puede realizar un control para recibir el mensaje de petición de autorización de servicio desde el terminal remoto.
Además, el transceptor 2610 de la entidad de red puede transmitir y recibir una señal de acuerdo con una operación cualquiera de las realizaciones anteriores. Por ejemplo, cuando la entidad de red es el AS de GCS, el transceptor 2610 de la entidad de red puede recibir la lista de ECGI desde el terminal. Como alternativa, cuando la entidad de red es la función de ProSe, el transceptor 2610 de la entidad de red puede recibir el mensaje de petición de autorización de servicio desde el terminal remoto.
Las realizaciones de la presente invención desvelada en la presente memoria descriptiva y los dibujos adjuntos se han proporcionado para describir fácilmente y ayudar en el entendimiento del contenido descrito y no limitan el ámbito de la presente invención. Es obvio para los expertos en la materia a la que pertenece la presente invención que pueden hacerse diversas modificaciones sin alejarse del ámbito de la presente invención, que se define mediante las reivindicaciones adjuntas, además de las realizaciones desveladas en el presente documento.
Mientras tanto, aunque las realizaciones ilustrativas de la presente invención se han ilustrado en la presente memoria descriptiva y los dibujos adjuntos y se han usado términos específicos, se usan en un significado general para ayudar en el entendimiento de la presente invención y no limitan el ámbito de la presente invención. Es obvio para los expertos en la materia a la que pertenece la presente invención que pueden hacerse diversas modificaciones sin alejarse del ámbito de la presente invención, que se define mediante las reivindicaciones adjuntas, además de las realizaciones ilustrativas desveladas en el presente documento.

Claims (12)

REIVINDICACIONES
1. Un procedimiento por un terminal (1510) remoto de soporte de un servicio en un sistema (1590) de comunicación inalámbrica, comprendiendo el procedimiento:
transmitir (1710), a un terminal (1520) de retransmisión, un mensaje de petición de supervisión de identificador de grupo móvil temporal, TMGI, que comprende un TGMI y prioridad por paquete de servicio basado en proximidad, ProSe, asociada con el TMGI;
recibir (1720), desde el terminal (1520) de retransmisión, un mensaje de respuesta de supervisión de TMGI que comprende un identificador de grupo de capa 2 de ProSe para la identificación de un grupo para la recepción de un tráfico de servicio de multidifusión de difusión multimedia, MBMS, que corresponde al TMGI; y
recibir (1740), desde el terminal (1520) de retransmisión, el tráfico de MBMS asociado con el identificador de grupo de capa 2 de ProSe,
en el que el tráfico de MBMS se transmite por el terminal de retransmisión a base de la prioridad por paquete de ProSe,
en el que el mensaje de petición de supervisión de TMGI comprende además identidades de área de servicio, SAI, de MBMS.
2. El procedimiento de la reivindicación 1,
en el que la prioridad por paquete de ProSe se obtiene a partir de una capa de aplicación en el terminal remoto.
3. El procedimiento de la reivindicación 1,
en el que el tráfico de MBMS se recibe a través de la interfaz PC5.
4. Un procedimiento por un terminal (1520) de retransmisión de soporte de un servicio en un sistema (1590) de comunicación inalámbrica, comprendiendo el procedimiento:
recibir (1710), desde un terminal (1510) remoto, un mensaje de petición de supervisión de identificador de grupo móvil temporal, TMGI, que comprende un TGMI y prioridad por paquete de servicio basado en proximidad, ProSe, asociada con el TMGI;
transmitir (1720), al terminal (1510) remoto, un mensaje de respuesta de supervisión de TMGI que comprende un identificador de grupo de capa 2 de ProSe para la identificación de un grupo para la transmisión de un tráfico de servicio de multidifusión de difusión multimedia, MBMS, que corresponde al TMGI; y
transmitir (1740), al terminal (1510) remoto, el tráfico de MBMS asociado con el identificador de grupo de capa 2 de ProSe a base de la prioridad por paquete de ProSe,
en el que el mensaje de petición de supervisión de TMGI comprende además identidades de área de servicio, SAI, de MBMS.
5. El procedimiento de la reivindicación 4,
en el que la prioridad por paquete de ProSe se obtiene a partir de una capa de aplicación en el terminal remoto.
6. El procedimiento de la reivindicación 4,
en el que el tráfico de MBMS se transmite a través de la interfaz PC5.
7. Un terminal (1510) remoto que comprende:
un transceptor; y
un controlador acoplado con el transceptor y configurado para
transmitir (1710), a un terminal (1520) de retransmisión, un mensaje de petición de supervisión de identificador de grupo móvil temporal, TMGI, que comprende un TGMI y prioridad por paquete de servicio basado en proximidad, ProSe, asociada con el TMGI,
recibir (1720), desde el terminal (1520) de retransmisión, un mensaje de respuesta de supervisión de TMGI que comprende un identificador de grupo de capa 2 de ProSe para la identificación de un grupo para la recepción de un tráfico de servicio de multidifusión de difusión multimedia, MBMS, que corresponde al Tm G i, y
recibir (1740), desde el terminal (1520) de retransmisión, el tráfico de MBMS asociado con el identificador de grupo de capa 2 de ProSe, en el que el tráfico de MBMS se transmite por el terminal de retransmisión a base de la prioridad por paquete de ProSe,
en el que el mensaje de petición de supervisión de TMGI comprende además identidades de área de servicio, SAI, de MBMS.
8. El terminal remoto de la reivindicación 7,
en el que el controlador se configura para obtener la prioridad por paquete de ProSe de una capa de aplicación en el terminal remoto.
9. El terminal remoto de la reivindicación 7,
en el que el controlador se configura para recibir el tráfico de MBMS a través de la interfaz PC5.
10. Un terminal (1520) de retransmisión que comprende:
un transceptor; y
un controlador acoplado con el transceptor y configurado para
recibir (1710), desde un terminal (1510) remoto, un mensaje de petición de supervisión de identificador de grupo móvil temporal, TMGI, que comprende un TGMI y prioridad por paquete de servicio basado en proximidad, ProSe, asociada con el TMGI,
transmitir (1720), al terminal (1510) remoto, un mensaje de respuesta de supervisión de TMGI que comprende un identificador de grupo de capa 2 de ProSe para la identificación de un grupo para la transmisión de un tráfico de servicio de multidifusión de difusión multimedia, MBMS, que corresponde al TMGI, y
transmitir (1740), al terminal (1510) remoto, el tráfico de MBMS asociado con el identificador de grupo de capa 2 de ProSe a base de la prioridad por paquete de ProSe,
en el que el mensaje de petición de supervisión de TMGI comprende además identidades de área de servicio, SAI, de MBMS.
11. El terminal de retransmisión de la reivindicación 10,
en el que la prioridad por paquete de ProSe se obtiene a partir de una capa de aplicación en el terminal remoto.
12. El terminal de retransmisión de la reivindicación 10,
en el que el controlador se configura para transmitir el tráfico de MBMS a través de la interfaz PC5.
ES16835400T 2015-08-07 2016-08-08 Terminal y procedimiento de comunicación del mismo Active ES2794566T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201562202406P 2015-08-07 2015-08-07
PCT/KR2016/008685 WO2017026760A1 (en) 2015-08-07 2016-08-08 Terminal and communication method of the same

Publications (1)

Publication Number Publication Date
ES2794566T3 true ES2794566T3 (es) 2020-11-18

Family

ID=57983806

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16835400T Active ES2794566T3 (es) 2015-08-07 2016-08-08 Terminal y procedimiento de comunicación del mismo

Country Status (6)

Country Link
US (2) US10231087B2 (es)
EP (2) EP3332577B1 (es)
KR (1) KR102628626B1 (es)
CN (1) CN107852637B (es)
ES (1) ES2794566T3 (es)
WO (1) WO2017026760A1 (es)

Families Citing this family (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016178526A1 (ko) * 2015-05-07 2016-11-10 엘지전자 주식회사 Mme가 mce와 연결된 기지국 정보를 수신하는 방법 및 장치
TWI688231B (zh) 2015-06-23 2020-03-11 美商內數位專利控股公司 ProSe通訊優先處理
WO2017026772A1 (ko) * 2015-08-09 2017-02-16 엘지전자 주식회사 무선 통신 시스템에서 p-cscf 선택 및 sip 메시지 전송 방법 및 이를 위한 장치
CN112040496A (zh) 2015-08-20 2020-12-04 华为技术有限公司 数据处理方法和设备
US10764903B2 (en) * 2015-09-25 2020-09-01 Telefonaktiebolaget Lm Ericsson (Publ) Per-packet resource pool selection in LTE V2X system
CN106961722B (zh) * 2016-01-12 2018-09-11 展讯通信（上海）有限公司 数据的传输方法及基站
WO2017160134A1 (ko) * 2016-03-18 2017-09-21 엘지전자 주식회사 셀 그룹 정보를 기반으로 v2x 통신을 수행하는 방법 및 장치
CN113556691B (zh) * 2016-04-01 2022-12-02 北京三星通信技术研究有限公司 一种发送v2x消息的方法及装置
US11463846B2 (en) * 2016-04-01 2022-10-04 Samsung Electronics Co., Ltd Method and apparatus for transmitting V2X message
US10277515B2 (en) * 2016-04-04 2019-04-30 Qualcomm Incorporated Quality of service (QOS) management in wireless networks
US10327252B2 (en) * 2016-06-20 2019-06-18 Lg Electronics Inc. Method and apparatus for receiving V2X message
US10090908B1 (en) * 2016-08-03 2018-10-02 Sprint Communications Company L.P. Data services for wireless communication devices that are attached to wireless repeater chains
WO2018058692A1 (zh) 2016-10-01 2018-04-05 华为技术有限公司 一种广播承载管理的方法及其设备
US10924912B2 (en) * 2017-01-06 2021-02-16 Lg Electronics Inc. Method for transmitting and receiving data through relay in wireless communication system and apparatus therefor
US10014972B1 (en) 2017-01-10 2018-07-03 Comcast Cable Communications, Llc Dynamically managing premises management traffic
US10484517B2 (en) * 2017-02-10 2019-11-19 Qualcomm Incorporated Quality of service support for layer 2 based device-to-device relay
US20200077253A1 (en) * 2017-03-10 2020-03-05 Lg Electronics Inc. Method for transmitting and receiving data using relay in wireless communication system, and apparatus therefor
KR102047884B1 (ko) 2017-03-20 2019-12-02 엘지전자 주식회사 세션을 관리하는 방법 및 smf 노드
US10772148B2 (en) 2017-04-28 2020-09-08 Kt Corporation Method and apparatus for managing PDU session between base station and core network in next-generation wireless network
WO2018204695A1 (en) 2017-05-05 2018-11-08 Kyocera Corporation Relaying of broadcast/multicast delivery from a relay ue to a remote ue
WO2018233809A1 (en) * 2017-06-20 2018-12-27 Motorola Mobility Llc METHODS AND APPARATUSES FOR PAGING A REMOTE UNIT VIA A DIRECT MOBILE CONNECTION
US10736070B2 (en) * 2017-07-26 2020-08-04 Blackberry Limited Method and system for use of a relay user equipment in an internet protocol multimedia subsystem
US20190036842A1 (en) * 2017-07-31 2019-01-31 Cisco Technology, Inc. Traffic steering in fastpath
US20190036814A1 (en) * 2017-07-31 2019-01-31 Cisco Technology, Inc. Traffic steering with path ordering
US10285026B2 (en) 2017-08-08 2019-05-07 T-Mobile Usa, Inc. Service sharing between devices
WO2019034005A1 (zh) * 2017-08-14 2019-02-21 华为技术有限公司 一种组播方法及装置
CN109769150B (zh) * 2017-11-09 2021-02-23 华为技术有限公司 一种传输组播业务的方法和设备
CN109788507B (zh) * 2017-11-13 2021-10-22 华为技术有限公司 通信方法和装置
US11202253B2 (en) * 2017-11-17 2021-12-14 Blackberry Limited PLMN selection for mission critical devices
CN108200178A (zh) * 2018-01-04 2018-06-22 海信集团有限公司 一种下载资源的方法和设备
CN112042167B (zh) * 2018-01-25 2023-04-18 诺基亚通信公司 用于在mec网络中处理用户服务简档信息的方法和装置
US20190313311A1 (en) * 2018-04-09 2019-10-10 Mediatek Inc. Apparatuses, service networks, and methods for handling plmn-specific parameters for an inter-plmn handover
JP6912729B2 (ja) * 2018-04-12 2021-08-04 日本電信電話株式会社 Ｓｉｐプロキシサーバ、通信方法およびｓｉｐプロキシプログラム
CN110557785B (zh) * 2018-05-30 2021-02-02 大唐移动通信设备有限公司 一种基于mec的数据分流方法及装置
CN112534840A (zh) * 2018-07-02 2021-03-19 康维达无线有限责任公司 5g延迟容忍数据服务
US11224091B2 (en) 2018-07-26 2022-01-11 Samsung Electronics Co., Ltd Method and apparatus for prioritizing mission critical push to talk traffic during an emergency
US11196674B2 (en) * 2018-11-09 2021-12-07 T-Mobile Usa, Inc. Message type mapping for packet traffic prioritization
CN109451484B (zh) * 2019-01-03 2021-12-10 中国联合网络通信集团有限公司 一种apn自动配置方法及系统
KR20200084614A (ko) * 2019-01-03 2020-07-13 삼성전자주식회사 IMS(IP multimedia subsystem) 서비스를 제공하는 전자 장치
CN112153558B (zh) * 2019-06-28 2021-10-22 华为技术有限公司 一种通信方法及装置
US11075973B2 (en) * 2019-10-23 2021-07-27 Verizon Patent And Licensing Inc. Systems and methods for prioritized sip services using UE-specified sip register messages
IL294555A (en) 2020-02-21 2022-09-01 Guangdong Oppo Mobile Telecommunications Corp Ltd Method to control qos, device and readable storage medium
CN113573327B (zh) * 2020-04-28 2023-11-10 维沃移动通信有限公司 远端ue的传输方法、配置方法、装置及电子设备
GB202007435D0 (en) * 2020-05-19 2020-07-01 Samsung Electronics Co Ltd Improvements in an relating to qos handling
CN112566136B (zh) * 2020-12-03 2023-05-05 恒安嘉新（北京）科技股份公司 基站小区覆盖关系的处理方法、装置及存储介质
US11558850B2 (en) * 2021-04-13 2023-01-17 Qualcomm Incorporated Methods for handling anomaly notification messages
US11792165B2 (en) 2021-06-04 2023-10-17 Bank Of America Corporation Supporting data processing transactions using machine to machine (M2M) data transfer
US11784981B2 (en) 2021-06-04 2023-10-10 Bank Of America Corporation Data processing transactions using machine to machine (M2M) data transfer
US11265370B1 (en) * 2021-07-27 2022-03-01 Bank Of America Corporation Machine to machine (M2M) data transfer between data servers

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3739640B2 (ja) 2000-08-28 2006-01-25 シャープ株式会社 液晶モジュールの製造方法
EP2048847A1 (en) * 2007-10-08 2009-04-15 Nokia Siemens Networks Oy Methods, apparatuses, system, and related computer program product for policy control
WO2010026287A1 (en) 2008-09-08 2010-03-11 Nokia Corporation Adaptive transmission modes for transparent relay
US9301191B2 (en) * 2013-09-20 2016-03-29 Telecommunication Systems, Inc. Quality of service to over the top applications used with VPN
US9072072B2 (en) * 2011-04-29 2015-06-30 Qualcomm Incorporated Methods and apparatuses for managing simultaneous unicast and multicast/broadcast services in a wireless communication system
US8837500B2 (en) 2011-06-23 2014-09-16 Alcatel Lucent Service data flow direction/redirection
US8750179B2 (en) 2011-08-15 2014-06-10 Blackberry Limited Efficient multimedia broadcast multicast service continuity methods
CA2850321A1 (en) 2011-09-30 2013-04-04 Interdigital Patent Holdings, Inc. Methods, apparatus and systems for enabling managed remote access
US20140016537A1 (en) 2012-05-04 2014-01-16 Qualcomm Incorporated Associating terminal user equipment with user equipment relays
US9191806B2 (en) * 2012-10-23 2015-11-17 Lg Electronics Inc. Method and apparatus for retransmitting MTC group message in wireless communication system
EP2833694A3 (en) * 2013-07-29 2015-04-01 HTC Corporation Method of relay discovery and communication in a wireless communications system
WO2015026111A1 (ko) 2013-08-18 2015-02-26 엘지전자 주식회사 무선 통신 시스템에서 중계기 동작 방법 및 장치
US10136266B2 (en) 2013-09-12 2018-11-20 Interdigital Patent Holdings, Inc. Group communication service enabler (GCSE) group management
WO2015119427A1 (en) 2014-02-04 2015-08-13 Lg Electronics Inc. Method and apparatus for notifying out-of-coverage for d2d operation in wireless communication system
KR102099642B1 (ko) 2014-03-31 2020-04-10 삼성전자 주식회사 단말 대 단말 통신에서 데이터 전송하는 방법 및 장치
US10079822B2 (en) * 2014-06-30 2018-09-18 Intel IP Corporation Techniques for securely receiving critical communication content associated with a critical communication service
WO2016024773A1 (ko) * 2014-08-10 2016-02-18 엘지전자 주식회사 무선 통신 시스템에서 릴레이 선택 방법 및 이를 위한 장치
EP3099109B1 (en) 2014-08-13 2019-10-02 Lg Electronics Inc. Method and user equipment for blocking network access according to application
US9674749B2 (en) 2014-08-14 2017-06-06 Samsung Electronics Co., Ltd. Method and apparatus for selecting dedicated core network
US20160100353A1 (en) * 2014-10-01 2016-04-07 Industrial Technology Research Institute Method of dynamic admission control applicable to prose server and user equipment and related apparatuses using the same
US10694496B2 (en) 2014-11-07 2020-06-23 Samsung Electronics Co., Ltd. Method and apparatus for transmitting group message to user equipment (UE)
TWI688231B (zh) * 2015-06-23 2020-03-11 美商內數位專利控股公司 ProSe通訊優先處理

Also Published As

Publication number Publication date
EP3332577A1 (en) 2018-06-13
EP3332577A4 (en) 2018-07-25
US20190208359A1 (en) 2019-07-04
KR20180029226A (ko) 2018-03-20
CN107852637B (zh) 2021-05-11
US20170041752A1 (en) 2017-02-09
KR102628626B1 (ko) 2024-01-25
US10631125B2 (en) 2020-04-21
EP3332577B1 (en) 2020-04-29
EP3709761A1 (en) 2020-09-16
EP3709761B1 (en) 2022-02-16
CN107852637A (zh) 2018-03-27
WO2017026760A1 (en) 2017-02-16
US10231087B2 (en) 2019-03-12

Similar Documents

Publication Publication Date Title
ES2794566T3 (es) Terminal y procedimiento de comunicación del mismo
US11627515B2 (en) Method for supporting lawful interception of remote ProSe UE in network
AU2017341625B2 (en) Method for applying reflective quality of service in wireless communication system, and device therefor
JP6695362B2 (ja) 場所ベースのコンテキスト配信
US11589208B2 (en) Method for transmitting data in CIoT system and device therefor
CN109997334B (zh) 具有用于3gpp网络中物联网应用的间接连接的中继和收费的会话管理
US10687175B2 (en) Method for transmitting and receiving V2X message in wireless communication system, and an apparatus for same
KR102262256B1 (ko) 네트워크를 슬라이스로 구성하여 단말에게 서비스를 제공하는 방법 및 장치
Taleb et al. Machine type communications in 3GPP networks: potential, challenges, and solutions
US10154475B2 (en) Method and device for selecting relay in wireless communication system
US20190191347A1 (en) Method and apparatus for providing services of network to terminal by using slice
EP3127366B1 (en) Overload control and coordination between m2m service layer and 3gpp networks
US9955490B2 (en) Radio communication apparatus, network node, user node, core network, and methods implemented therein
US20190110175A1 (en) Method and user equipment for transmitting data unit, and method and user equipment for receiving data unit
US9473877B2 (en) Uplink/downlink transmission method for small amount of data, and corresponding terminal and mobility management unit
US10313909B2 (en) Method and device for cell granularity reporting in wireless communication system
Liebhart et al. LTE for public safety
US10587532B2 (en) Technique for providing content via a mobile communications network