ES2795435T3 - Procedimiento y aparato de implementación de servicio en sistema de comunicación inalámbrica - Google Patents
Procedimiento y aparato de implementación de servicio en sistema de comunicación inalámbrica Download PDFInfo
- Publication number
- ES2795435T3 ES2795435T3 ES16811927T ES16811927T ES2795435T3 ES 2795435 T3 ES2795435 T3 ES 2795435T3 ES 16811927 T ES16811927 T ES 16811927T ES 16811927 T ES16811927 T ES 16811927T ES 2795435 T3 ES2795435 T3 ES 2795435T3
- Authority
- ES
- Spain
- Prior art keywords
- service
- sip
- message
- way
- terminal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- 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
- H04W4/10—Push-to-Talk [PTT] or Push-On-Call services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1073—Registration or de-registration
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
- H04L65/4061—Push-to services, e.g. push-to-talk or push-to-video
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/12—Setup of transport tunnels
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/15—Setup of multiple wireless link connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/30—Connection release
- H04W76/34—Selective release of ongoing connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/50—Connection management for emergency connections
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Telephonic Communication Services (AREA)
- Computer Security & Cryptography (AREA)
Abstract
Un procedimiento por un primer terminal (201-1701) en un sistema de comunicación, comprendiendo el procedimiento: registrar con un servidor (205-1705) transmitiendo un mensaje de registro al servidor (205-1705); transmitir, en caso de que se active un primer servicio unidireccional basándose en un sensor del primer terminal, un primer mensaje de solicitud de servicio que incluye información que solicita el primer servicio unidireccional al servidor (205-1705); recibir, de un segundo terminal (309, 409, 508, 609-809, 911-1211, 1307-1507, 1609, 1707), un mensaje de respuesta para aceptar el primer servicio unidireccional; transmitir, al segundo terminal (309, 409, 508, 609-809, 911-1211, 1307-1507, 1609, 1707), un mensaje de acuse de recibo, ACK, para el mensaje de respuesta; y establecer una primera sesión de medios para el primer servicio unidireccional con el segundo terminal (309, 409, 508, 609-809, 911-1211, 1307-1507, 1609, 1707), usándose únicamente la primera sesión de medios para que el primer terminal (201-1701) transmita datos, en el que el primer mensaje de solicitud de servicio incluye un modo de comienzo de servicio que indica si una primera solicitud de servicio ha de aceptarse automática o manualmente y al menos uno de un subsistema multimedia de IP, IMS, un identificador de servicio de comunicación, ICSI, y un identificador de referencia de aplicación de IMS, IARI, que indica el primer servicio unidireccional.
Description
DESCRIPCIÓN
Procedimiento y aparato de implementación de servicio en sistema de comunicación inalámbrica
rCampo técnico!
La presente divulgación se refiere a un procedimiento de implementación de servicio y un correspondiente aparato para transmitir contenido de medios recopilados por un terminal en un sistema de comunicación inalámbrica.
Antecedentes de la técnica!
Para cumplir la creciente demanda de tráfico de datos inalámbricos desde la comercialización de los sistemas de comunicación de la 4a generación (4G), el foco de desarrollo se encuentra en el sistema de comunicación de la 5a generación (5G) o pre-5G. Por esta razón, el sistema de comunicación de 5G o pre-5G se denomina más adelante sistema de comunicación de red 4G o sistema de pos Evolución a Largo Plazo (LTE). Para conseguir altas tasas de datos, se está proporcionando consideración a implementar el sistema de comunicación de 5G en la banda (por ejemplo, banda 60 Ghz) de onda milimétrica (Onda mm). Para mitigar la pérdida de propagación y aumentar la distancia de propagación, el sistema de comunicación de 5G es probable que adapte diversas técnicas tales como formación de haces, múltiple entrada múltiple salida (MIMO) masiva, MIMO dimensional completa (FD-MIMO), antenas en serie, formación de haces analógica y antena de gran escala. También, para mejora de caudal del sistema de comunicación de 5G, se están realizando investigaciones en diversas técnicas tales como célula pequeña, célula pequeña avanzada, red de acceso de radio en la nube (RAN en la nube), red ultra-densa, comunicación de dispositivo a dispositivo (D2D), enlace de retroceso inalámbrico, red en movimiento, comunicación cooperativa, múltiples puntos coordinados (CoMP), y cancelación de interferencia. Adicionalmente, la investigación en curso incluye el uso de modulación por desplazamiento de frecuencia híbrida (FSK híbrida) y la modulación por amplitud en cuadratura (QAM) y codificación de superposición de ventana de deslizamiento (SWSC) como modulación de codificación avanzada (ACM), múltiples portadoras de banco de filtros (FBMC), acceso múltiple no ortogonal (NOMA), y acceso múltiple de código disperso (SCMA).
Mientras tanto, Internet está evolucionando de una red de comunicación centrada en humanos en la que se genera información y se consume por humanos hasta el Internet de las Cosas (loT) en el que las cosas o componentes distribuidos intercambian y procesan información. La combinación de la tecnología de procesamiento de grandes cantidades de datos basadas en servidor en la nube y el loT engendra la Internet de la tecnología del todo. Para asegurar la tecnología de detección, la comunicación alámbrica/inalámbrica y la infraestructura de red, la tecnología de interfaz de servicio, y la tecnología de seguridad requerida para implementar el loT, la investigación reciente se ha centrado en la tecnología de la red de sensores, comunicación de máquina a máquina (M2M), y comunicación de tipo máquina (MTC). En el entorno de loT, es posible proporcionar una tecnología de Internet (TI) inteligente que puede recopilar y analizar datos generados de cosas conectadas para crear nuevos valores para la vida humana. La loT puede aplicarse a diversos campos tales como un hogar inteligente, un edificio inteligente, una ciudad inteligente, un coche inteligente o un coche conectado, una red eléctrica inteligente, cuidado de la salud, un electrodoméstico inteligente, y un servicio médico inteligente a través de IT heredado y la convergencia de diversas industrias.
Por lo tanto, hay varios intentos para aplicar la loT al sistema de comunicación de 5G. Por ejemplo, las tecnologías de la red de sensores, M2M, y MTC se implementan por medio de las tecnologías de comunicación de 5G tales como formación de haces, MIMO y una antena de conjunto. La aplicación de la RAN en la nube anteriormente mencionada como una tecnología de procesamiento de grandes cantidades de datos es un ejemplo de convergencia entre las tecnologías de 5G y loT.
La publicación del 3GPP "Study on application architecture to support Mission Critical Push To Talk over LTE (MCPTT) services" (TR 23.779; versión 1.0.0) contiene resultados del estudio de la Etapa 2 y la evaluación de posibles soluciones de sistema técnico del 3GPP para MCPTT a través de la aplicación de LTE y, entre otras cosas, desvela que pueden establecerse llamadas privadas usando un control de nivel mínimo (es decir llamadas semi-dúplex) o sin usar un control de nivel mínimo (es decir llamadas privadas de dúplex completo). Sin embargo, ambos de estos modos - semi dúplex y dúplex completo - posibilitan que ambos terminales participantes en la comunicación envíen y reciban datos a/desde el otro terminal. Además, no se realiza mención a las llamadas que se activan por un sensor del terminal.
Mientras tanto, la seguridad pública de LTE (PS-LTE) proporciona a un usuario con un servicio de comunicación para seguridad pública en una situación frente a desastre usando pulsar para hablar de misión crítica (MCPTT) a través de LTE.
Para este fin, un terminal puede estar configurado para obtener contenido de medios en sus alrededores en una situación de emergencia y transmitir el contenido de medios a un gestor de situación de emergencia como ayuda.
Existe por lo tanto una necesidad de un procedimiento para obtener contenido de medios en los alrededores del terminal en una situación de emergencia y la transmisión del contenido de medios a un gestor de situación de emergencia.
La información anterior se presenta como información de antecedentes únicamente para ayudar a una comprensión
de la presente divulgación. No se ha realizado determinación alguna, y no se hace afirmación alguna, en lo que respecta a si algo de lo anterior podría ser aplicable como técnica anterior con respecto a la presente divulgación.
Divulgación de la invención!
Problema técnico!
Existe por lo tanto una necesidad de un procedimiento para obtener contenido de medios en los alrededores del terminal en una situación de emergencia y la transmisión del contenido de medios a un gestor de situación de emergencia.
rSolución al problema!
La invención se define en las reivindicaciones adjuntas.
rEfectos ventajosos de la invención!
De acuerdo con la presente invención, cuando tiene lugar una emergencia, los medios recopilados por el terminal se transmiten al gestor y pueden ayudar a la emergencia.
[Breve descripción de los dibujos!
Los anteriores y otros aspectos, características, y ventajas de ciertas realizaciones de la presente divulgación se harán más evidentes a partir de la siguiente descripción tomada en conjunto con los dibujos adjuntos, en los que:
La Figura 1 es un diagrama que ilustra una arquitectura de sistema de pulsar para hablar de misión crítica (MCPTT) de acuerdo con una realización de la presente divulgación;
La Figura 2 es un diagrama de flujo de señal que ilustra un procedimiento de registro de un equipo de usuario (UE) que tiene una capacidad de servicio unidireccional con un núcleo de protocolo de iniciación de sesión (SIP) y un servidor de MCPTT de acuerdo con una realización de la presente divulgación;
La Figura 3 es un diagrama de flujo de señal que ilustra un procedimiento de iniciación de servicio unidireccional iniciado por UE llamante de acuerdo con una realización de la presente divulgación;
La Figura 4 es un diagrama de flujo de señal que ilustra un procedimiento de iniciación de servicio unidireccional iniciado por UE llamado de acuerdo con una realización de la presente divulgación;
La Figura 5 es un diagrama de flujo de señal que ilustra un procedimiento para un UE que está proporcionando un servicio unidireccional para iniciar un nuevo servicio unidireccional tras la recepción de una solicitud de servicio unidireccional de otro UE de acuerdo con una realización de la presente divulgación;
La Figura 6 es un diagrama de flujo de señal que ilustra un procedimiento para que un servidor de MCPTT libere un servicio unidireccional en curso de acuerdo con una realización de la presente divulgación;
La Figura 7 es un diagrama de flujo de señal que ilustra un procedimiento para rechazar una solicitud de nuevo servicio unidireccional de un nuevo UE de acuerdo con una realización de la presente divulgación;
La Figura 8 es un diagrama de flujo de señal que ilustra un procedimiento para que un servidor de MCPTT rechace una solicitud de servicio unidireccional de un UE de acuerdo con una realización de la presente divulgación; Las Figuras 9A y 9B son un diagrama de flujo de señal que ilustra un procedimiento de aceptación de una solicitud de servicio recibida durante un servicio unidireccional en curso de acuerdo con diversas realizaciones de la presente divulgación;
La Figura 10 es un procedimiento para rechazar una solicitud de servicio durante un servicio unidireccional en curso de acuerdo con una realización de la presente divulgación;
Las Figuras 11A y 11B se refieren a un procedimiento para que un servidor de MCPTT libere un servicio unidireccional en curso cuando se establece una sesión entre un primer y un tercer UE además del servicio unidireccional en curso compartiendo la información en los UE a través de un acuerdo de nivel de aplicación entre el servidor de MCPTT y un servidor de aplicación (AS) de acuerdo con diversas realizaciones de la presente divulgación;
Las Figuras 12A y 12B son un diagrama de flujo de señal que ilustra un procedimiento para que un servidor de MCPTT libere un servicio en curso establecido entre un primer y un segundo UE tras la recepción de una nueva solicitud de servicio de un tercer UE de acuerdo con diversas realizaciones de la presente divulgación;
La Figura 13 es un diagrama de flujo de señal que ilustra un procedimiento para que un UE libere un servicio unidireccional en curso de acuerdo con una realización de la presente divulgación;
La Figura 14 es un diagrama de flujo de señal que ilustra un procedimiento para que un UE libere un servicio unidireccional usando un mensaje SIP re-INVITE en lugar de un mensaje SIP BYE de acuerdo con una realización de la presente divulgación;
La Figura 15 es un diagrama de flujo de señal que ilustra un procedimiento para que un segundo UE libere un servicio unidireccional de acuerdo con una realización de la presente divulgación;
La Figura 16 es un diagrama de flujo de señal que ilustra un procedimiento para que un servidor de MCPTT libere un servicio unidireccional de acuerdo con una realización de la presente divulgación;
La Figura 17 es un diagrama de flujo de señal que ilustra un procedimiento para rechazo de una solicitud de liberación de servicio unidireccional realizada por un UE que no tiene derecho a liberar el servicio unidireccional de acuerdo con una realización de la presente divulgación;
La Figura 18 es un diagrama de bloques que ilustra una configuración de un UE de acuerdo con una realización de la presente divulgación; y
La Figura 19 es un diagrama de bloques que ilustra una configuración de un servidor de acuerdo con una realización de la presente divulgación.
Los mismos números de referencia se usan para representar los mismos elementos a través de todos los dibujos.
rModo para la invención!
La siguiente descripción con referencia a los dibujos adjuntos se proporciona para ayudar en una comprensión detallada de diversas realizaciones de la presente divulgación tal como es definida por las reivindicaciones y sus equivalentes. Incluye diversos detalles específicos para ayudar en ese entendimiento, pero estos han de considerarse como meramente ilustrativos. Por consiguiente, los expertos en la materia reconocerán que pueden realizarse diversos cambios y modificaciones de las diversas realizaciones descritas en el presente documento. Además, por razones de claridad y concisión se pueden omitir las descripciones de funciones y construcciones bien conocidas. El ámbito de protección se define por las reivindicaciones adjuntas.
Las expresiones y términos usados en la siguiente descripción y reivindicaciones no se limitan a los significados bibliográficos, sino que son usados meramente por el inventor de la presente invención para habilitar una comprensión clara y consistente de la presente divulgación. Por consiguiente, debería ser evidente a los expertos en la materia que la siguiente descripción de diversas realizaciones de la presente divulgación se proporciona solo para fines de ilustración y no para el fin de limitar la presente divulgación tal como es definida por las reivindicaciones adjuntas y sus equivalentes.
Se ha de entender que las formas singulares "un", "una", "el" y "la" incluyen referentes plurales, salvo que el contexto dicte claramente otra cosa. Por lo tanto, por ejemplo, la referencia a "una superficie de componente" incluye la referencia a una o más de tales superficies.
En la siguiente divulgación, se exageran, omiten o simplifican algunos elementos en los dibujos y en la práctica los elementos pueden tener tamaños y/o formas diferentes de aquellos mostrados en los dibujos.
Se entenderá que cada bloque de las ilustraciones de diagrama de flujo y/o diagramas de bloques, y combinaciones de bloques en las ilustraciones de diagrama de flujo y/o diagramas de bloques, pueden implementarse por instrucciones de programa informático. Estas instrucciones de programa informático pueden proporcionarse a un procesador de un ordenador de fin general, ordenador de fin especial, u otro aparato de procesamiento de datos programable para producir una máquina, de manera que las instrucciones, que se ejecutan mediante el procesador del ordenador u otro aparato de procesamiento de datos programable, crean medios para implementar las funciones/actos especificados en el bloque o bloques de diagrama de flujo y/o diagrama de bloques. Estas instrucciones de programa informático pueden almacenarse también en una memoria legible por ordenador no transitoria que puede dirigir un ordenador u otro aparato de procesamiento programable para funcionar de una manera particular, de manera que las instrucciones almacenadas en la memoria legible por ordenador no transitoria producen un artículo de fabricación que incluye medios de instrucción que implementan la función/acto especificado en el diagrama de flujo y/o bloque o bloques del diagrama de bloques. Las instrucciones de programa informático pueden cargarse también en un ordenador u otro aparato de procesamiento programable para provocar que se realice una serie de operaciones en el ordenador u otro aparato programable para producir un procedimiento implementado por ordenador de manera que las instrucciones que se ejecutan en el ordenador u otro aparato programable proporcionan operaciones para implementar las funciones/actos especificados en el diagrama de flujo y/o bloque o bloques del diagrama de bloques.
Adicionalmente, los respectivos diagramas de bloques pueden ilustrar partes de módulos, segmentos o códigos que incluyen al menos una o más instrucciones ejecutables para realizar función o funciones lógicas específicas. Además, debería observarse que las funciones de los bloques pueden realizarse en orden diferente en varias modificaciones. Por ejemplo, dos bloques sucesivos pueden realizarse sustancialmente al mismo tiempo, o pueden realizarse en orden inverso de acuerdo con las funciones de los mismos.
De acuerdo con diversas realizaciones de la presente divulgación, el término "módulo", significa, pero sin limitación, un componente de software o hardware, tal como un campo de matriz de puertas programables (FPGA) o circuito integrado específico de la aplicación (ASIC), que realiza ciertas tareas. Un módulo puede estar configurado ventajosamente para residir en el medio de almacenamiento direccionable y configurado para ejecutarse en uno o más procesadores. Por lo tanto, un módulo puede incluir, a modo de ejemplo, componentes, tales como componentes de software, componentes de software orientado a objetos, componentes de clase y componentes de tarea, procedimientos, funciones, atributos, procedimientos, subrutinas, segmentos de código de programa, controladores, firmware, microcódigo, circuitería, datos, bases de datos, estructuras de datos, tablas, conjuntos y variables. La funcionalidad proporcionada en los componentes y módulos puede combinarse en menos componentes y módulos o separarse adicionalmente en componentes y módulos adicionales. Además, los componentes y módulos pueden implementarse de manera que ejecutan una o más unidades de procesamiento central (CPU) en un dispositivo o una tarjeta multimedia segura.
La Figura 1 es un diagrama que ilustra una arquitectura de sistema de pulsar para hablar de misión crítica (MCPTT) de acuerdo con una realización de la presente divulgación.
Haciendo referencia a la Figura 1, el sistema de MCPTT incluye un equipo de usuario (UE) 105, entidades de núcleo de protocolo de iniciación de sesión (SIP) 110, 115, y 120, un servidor de aplicación de MCPTT (AS de MCPTT) 125, y bases de datos (BD) 130 y 135.
Las BD pueden incluir una BD (BD de HSS) de servidores de abonados domésticos (HSS) 130 como una BD de núcleo de SIP y una BD 135 de usuarios de MCPTT. La BD 130 de HSS y la BD 135 de usuarios de MCPTT pueden almacenar información de usuario.
El UE 105 se conecta a una red externa mediante la entidad 110 de núcleo de SIP para proporcionar al usuario con el servicio de MCPTT. En más detalle, el UE 105 puede conectarse al AS de MCPTT 125 mediante las entidades 110, 115, y 120 de núcleo de SIP para comunicación con la red externa. En la siguiente descripción, el término "UE" se usa de manera intercambiable con los términos y expresiones "terminal" y "terminal de MCPTT".
Los terminales de MCPTT pueden clasificare como un terminal de MCPTT típico (no oficial), un terminal de MCPTT oficial, y un proveedor de servicio de MCPTT oficial.
El terminal de MCPTT puede recibir el servicio de MCPTT de múltiples proveedores de servicio de MCPTT. El terminal de MCPTT es apto de la realización de un grupo de comunicación o comunicación entre pares en conexión con un cierto proveedor de servicio de MCPTT que tiene una asociación además del proveedor de servicio de MCPTT principal del terminal de MCPTT.
El terminal de MCPTT puede recibir información básica con respecto al servicio de MCPTT del proveedor de servicio de MCPTT. La información básica puede incluir un identificador de usuario, un identificador de grupo, un papel de intra-grupo y tipo de llamada permitido, una capacidad de llamada entre pares, un tipo de disposición, información a informarse al servidor de MCPTT, e información para conectar a PostScript Encapsulado (EPS), núcleo de SIP, y AS de MCPTT para soportar diversos tipos de disposición.
El AS de MCPTT 125 puede proporcionar a los usuarios con un servicio de comunicación de situación frente a desastres o seguridad pública que incluye una función de llamada de grupo, una llamada entre pares, una llamada de emergencia, una alerta frente a desastres y una función de transmisión de contenido de medios de los alrededores recopilados por el UE.
En más detalle, el servicio de MCPTT puede estar categorizado en una llamada de grupo, una llamada entre pares, y una alerta de emergencia.
La llamada de grupo puede soportar una llamada de grupo normal para comunicación de grupo para seguridad pública, una llamada de emergencia servida con prioridad en una situación urgente/de emergencia, y una llamada riesgo inminente servida para comunicación de grupo en una situación inminente/de emergencia con una prioridad inferior que la de la llamada de emergencia.
La llamada entre pares puede soportar un servicio de llamada normal y de emergencia y un servicio de transmisión de contenido de medios que puede transmitir/recibir el contenido de medios circundante recopilado por el UE. El servicio de transmisión de contenido de medios de acuerdo con una realización de la presente divulgación está caracterizado porque el contenido de medios se transmite en una dirección a diferencia de la llamada normal heredada y la llamada de emergencia. Es decir, el UE llamante puede transmitir únicamente el contenido de medios, y el UE llamado puede únicamente recibir el contenido de medios. En la siguiente descripción, un servicio de transmisión de contenido de medios unidireccionales de este tipo se denomina de manera intercambiable como escucha ambiente. El contenido de medios transmitido unidireccionalmente puede incluir sonido e imagen que rodea al UE de la parte opuesta. El servicio unidireccional puede iniciarse por la parte llamante o un gestor que desea recibir el contenido de medios.
El servicio de MCPTT puede proporcionarse por el UE, el sistema de paquetes evolucionado (EPS), el núcleo de SIP, y el AS de MCPTT. En este momento, el EPS puede indicar una red de la evolución a largo plazo (LTE), y el núcleo de SIP puede ser una entidad de red que usa SIP tal como un subsistema multimedia (IMS) del protocolo de Internet (IP). Es decir, el servicio de MCPTT puede proporcionarse a través de la red de LTE y la red de IMS.
El servicio de MCPTT puede dividirse en una función de gestión de grupo, una función de control de sesión y una función de control de transmisión de medios.
La función de gestión de grupo puede incluir la gestión de información de suscripción del grupo al que pertenece el usuario, prioridad del grupo, papel permitido en el grupo, y tipo de llamada disponible en el grupo.
La función de control de sesión puede incluir el control de señales con respecto a una sesión de llamada tal como el registro del usuario con el servicio de MCPTT y el inicio, cambio o terminación de un grupo de comunicación.
La función de control de transmisión de medios puede incluir permitir la transmisión/recepción de contenido de medios
con respecto a la llamada de grupo, llamada entre pares y alerta frente a desastre y control de recursos. Todos los contenidos de medios transmitidos por el UE de MCPTT se entregan a un UE de la parte opuesta a través de una pasarela de medios proporcionada por el servicio de MCPTT.
El servidor de gestión de grupo para gestionar grupos puede estar co-ubicado con el AS de MCPTT y lógicamente separado de acuerdo con sus funciones.
La pasarela de medios para control de los contenidos de medios puede conectarse al UE, al EPS, y al AS de MCPTT sin implicación del núcleo de SIP. La pasarela de medios controla el derecho de transmisión/recepción del usuario, y esta operación de control se denomina como control de nivel mínimo. La pasarela de medios puede estar co-ubicada con el AS de MCPTT y son responsables de funciones lógicamente separadas.
El servicio de MCPTT puede proporcionarse de diversas maneras. El proveedor de MCPTT puede poseer todo del EPS, núcleo de SIP, y MPTT AS, o solamente el núcleo de SIP y AS de MCPTT que interoperan con el EPS poseído por otro proveedor. También, el proveedor de MCPTT puede poseer únicamente el AS de MCPTT que interopera con el núcleo de EPS y SIP poseído por otro proveedor.
El UE 105 y el AS de MCPTT 125 pueden usar un identificador de servicio de comunicación (ICSI) de IMS y/o un identificador de referencia de aplicación (IARI) de IMS para el servicio unidireccional. El UE 105 y el AS de MCPTT 125 pueden definir el servicio de MCPTT o servicio unidireccional basándose en el ICSI. El UE 105 y el AS de MCPTT 125 pueden definir también el servicio de MCPTT o servicio unidireccional basándose en el IARI. Por consiguiente, el UE 105 y el AS de MCPTT 125 pueden usar al menos uno o una combinación del ICSI e IARI para identificar el servicio unidireccional.
La Figura 2 es un diagrama de flujo de señal que ilustra un procedimiento de registro de un UE que tiene una capacidad de servicio unidireccional con un núcleo de SIP y un servidor de MCPTT de acuerdo con una realización de la presente divulgación.
Haciendo referencia a la Figura 2, un UE 201 puede enviar al núcleo 203 de SIP un mensaje SIP REGISTER en la operación S210 que incluye al menos uno de ICSI y IARI que indican un servicio unidireccional para su registro con el núcleo 203 de SIP y un servidor 205 de MCPTT. Es decir, el UE 201 puede transmitir el mensaje SIP REGISTER al núcleo 203 de SIP a través de la red de IMS.
Si se recibe el mensaje SIP REGISTER, el núcleo 203 de SIP puede enviar al UE 201 un mensaje SIP 200 OK que notifica de la recepción del mensaje de registro en la operación S220.
Si se recibe el mensaje SIP REGISTER, el núcleo 203 de SIP puede reenviar el mensaje SIP REGISTER al servidor 205 de MCPTT en la operación S230. Si se recibe el mensaje SIP REGISTER, el servidor 205 de MCPTT puede comprobar la información de UE incluida en el mensaje SIP REGISTER para determinar si registrar el UE 201 con el servidor en la operación S240.
Posteriormente, el servidor 205 de MCPTT puede realizar autenticación de autoridad basándose en la información incluida en el mensaje SIP REGISTER en la operación S250. Es decir, el servidor 205 de MCPTT puede determinar si registrar el UE 201 con el servidor dependiendo de si el UE 201 tiene la capacidad de servicio unidireccional y se ha abonado al servicio de MCPTT.
Si se determina registrar el UE 201, el servidor 205 de MCPTT puede enviar al núcleo 203 de SIP un mensaje SIP 200 OK en la operación S260.
Después de que se complete el registro, el UE 201 puede enviar al núcleo 203 de SIP un mensaje SIP SUBSCRIBE en la operación S270.
La Figura 3 es un diagrama de flujo de señal que ilustra un procedimiento de iniciación de servicio unidireccional iniciado por UE llamante de acuerdo con una realización de la presente divulgación.
Haciendo referencia a la Figura 3, el usuario puede hacer una entrada a través de una interfaz de usuario (UI) de un UE para iniciar el servicio unidireccional. Si se detecta una necesidad de servicio unidireccional por medio de un sensor del UE, el UE puede iniciar el servicio unidireccional de acuerdo con una realización de la presente divulgación.
Para iniciar el servicio unidireccional, el primer UE 301 puede enviar al núcleo 303 de SIP un mensaje SIP INVITE en la operación S310. En este momento, el mensaje SIP INVITE puede incluir al menos uno de ICSI y IARI que indican el servicio unidireccional. El UE 301 puede transmitir el mensaje SIP INVITE al núcleo 203 de SIP a través de una red de IMS.
En el dibujo, el primer UE 301 puede ser el UE de un usuario en una situación de emergencia.
El servicio unidireccional indica un servicio para que un primer UE transmita contenido de medios recopilado a un segundo UE a través de una ruta de medios unidireccional. En este momento, el contenido de medios recopilado por el primer UE puede incluir sonido ambiente e imágenes alrededor del primer UE. La ruta de medios unidireccional
puede configurarse usando uno de los siguientes dos procedimientos.
El primer procedimiento es para configurar un valor de protocolo de descripción de sesión (SDP) del mensaje SIP INVITE en el primer UE. Para solicitar el servicio unidireccional, el primer UE puede establecer el SDP a a=sendonly (únicamente envío). Es decir, el primer UE puede transmitir el mensaje INVITE que incluye la información que ordena la transmisión únicamente pero no la recepción.
En el caso de que el segundo UE esté recibiendo solicitudes de servicio unidireccional para el servicio unidireccional, el segundo UE establece el SDP a a=rcvonly (únicamente recepción) en el mensaje SIP INVITE. Es decir, el segundo UE puede transmitir el mensaje INVITE que incluye la información que ordena la recepción únicamente pero no la transmisión.
El segundo procedimiento es para usar una función de control de nivel mínimo de una pasarela de medios que controla la correcta transmisión/recepción del usuario. Como se ha descrito anteriormente, la pasarela de medios puede estar co-ubicada con el MCPTT y es responsable de una función lógicamente separada.
El AS de MCPTT puede configurarse para asignar el control de flujo correcto al UE de MCPTT automáticamente basándose en la información de usuario de servicio y en la información de servicio incluidas en el mensaje SIP INVITE y el mensaje SIP 200 OK o en respuesta a la solicitud del UE de MCPTT de manera que únicamente el Ue de MCPTT transmite contenido de medios. En este momento, el contenido de medios puede incluir todas las clases de objetos de medios (tales como audio, video, textos y ficheros) transmisibles por el UE de MCPTT.
El UE puede determinar una condición para iniciar el servicio unidireccional solicitado e incluir la condición en el mensaje INVITE.
Mientras tanto, se inicia un servicio de llamada normal en respuesta a una presión del usuario en un botón de llamada que aparece cuando se recibe una llamada entrante. Sin embargo, el servicio unidireccional de acuerdo con una realización de la presente divulgación puede iniciarse en respuesta a una acción de usuario explícita como presionar el botón de llamada o automáticamente tras la recepción de una solicitud de servicio sin acción de usuario explícita. Esto se denomina modo de comienzo de servicio llamado, y el modo de comienzo de servicio puede configurarse como sigue.
El modo de comienzo de servicio puede categorizarse en un modo de comienzo manual en el que comienza el servicio tras la entrada de usuario en respuesta a una solicitud de servicio (similar al servicio de llamada normal) y un modo de comienzo automático en el que comienza el servicio tras la recepción de la solicitud de servicio sin ninguna entrada de usuario. El modo de comienzo de servicio puede determinarse por el UE que solicita el servicio.
Por consiguiente, el UE 301 puede enviar al núcleo 303 de SIP el mensaje SIP INVITE que incluye la información acerca del modo de comienzo de servicio. Por ejemplo, el UE puede añadir un encabezamiento predeterminado al modo de comienzo de servicio al mensaje para que se transmita al núcleo 303 de SIP.
El modo de comienzo de servicio puede determinarse por el UE que recibe la solicitud de servicio. En el caso de que el UE que ha recibido la solicitud de servicio determine el modo de comienzo de servicio, el UE puede tener prioridades específicas de servicio para determinar el modo de comienzo de servicio dependiendo del servicio a recibirse.
El procedimiento de determinación de modo de comienzo de servicio no está limitado al servicio unidireccional sino que puede aplicarse a los servicios de contenido de medios que pueden transmitir/recibir contenido de medios ambiente de la parte opuesta en una situación de emergencia.
Si se recibe el mensaje SIP INVITE en la operación S310, el núcleo 303 de SIP puede reenviar el mensaje SIP INVITE al servidor 305 de mCpTT en la operación S320.
Si se recibe el mensaje SIP INVITE, el servidor 305 de MCPTT puede realizar una comprobación de contexto con el servidor 307 de gestión de grupo de MCPTT y realizar autenticación de autoridad para determinar en la operación S330 si el UE que ha solicitado el servicio unidireccional tiene la capacidad de servicio unidireccional y capacidad de configuración de modo de comienzo de servicio. Para la autenticación de autoridad, el servidor 305 de MCPTT puede obtener información básica de la HSS-BD 130, la BD 135 de usuarios de MCPTT, y el núcleo de SIP. Si se completa satisfactoriamente la autenticación de autoridad, el servidor 305 de MCPTT puede reenviar el mensaje INVITE al segundo UE 309 mediante el núcleo 303 de SIP en la operación S340.
El segundo UE 309 es un UE para realizar el servicio unidireccional con el primer UE 301. En la Figura 3, el segundo UE 309 puede ser un gestor de servicio para gestionar situaciones de emergencia. Sin embargo, el segundo UE 309 no está limitado al gestor de servicio y puede ser un UE de propiedad por el usuario.
Si se recibe el mensaje INVITE, el segundo UE 309 envía al primer UE 301 un mensaje SIP 200 OK mediante el núcleo 303 de SIP y el servidor 305 de MCPTT para aceptar la solicitud de servicio unidireccional en la operación S350.
Si se recibe el mensaje SIP 200 OK, el primer UE 301 envía al segundo UE 309 un mensaje de acuse de recibo de SIP (ACK) mediante el núcleo 303 de SIP y el servidor 305 de MCPTT para completar el comienzo de servicio en la
operación S360. En este momento, el mensaje SIP 200 OK y mensaje de ACK de SIP se transmiten a través de la misma ruta que el mensaje SIP INVITE. Sin embargo, los mensajes pueden transmitirse también a través de una ruta diferente desde los mismos.
Posteriormente, se establece una sesión de medios entre el primer y segundo UE 301 y 309 en la operación S370.
El servicio unidireccional puede iniciarse por el UE llamado que proporciona el contenido de medios ambiente así como el UE llamante que recibe el contenido de medios. El servicio unidireccional puede también activarse automáticamente por el Ue llamante que transmite el contenido de medios.
Por ejemplo, el servicio unidireccional puede activarse automáticamente por un sensor del UE de propiedad por el usuario. El UE puede ser cualquiera de un teléfono inteligente, un ordenador personal (PC) de tableta, y un reloj inteligente, y puede recopilar la información de estado actual e información de situación ambiente del usuario del UE usando diversos sensores tales como un sensor de giroscopio, un sensor de pulso de frecuencia cardiaca y el sensor de temperatura. Si un valor que corresponde a la información recopilada es mayor que un valor umbral predeterminado, el servicio unidireccional se activa automáticamente.
La Figura 4 es un diagrama de flujo de señal que ilustra un procedimiento de iniciación de servicio unidireccional iniciado por UE llamado de acuerdo con una realización de la presente divulgación.
Haciendo referencia a la Figura 4, un segundo UE 409 puede enviar al núcleo 403 de SIP un mensaje SIP INVITE para solicitar el servicio universal en la operación S410. En este momento, el mensaje SIP INVITE puede incluir la información que indica que el servicio solicitado es el servicio unidireccional. Es decir, el segundo UE puede establecer el SDP del mensaje SIP INVITE a a=rcvonly (únicamente recepción).
El mensaje SIP INVITE puede incluir también información de modo de comienzo de servicio. El modo de comienzo de servicio se ha descrito con referencia a la Figura 3 y por lo tanto se omite en el presente documento una descripción detallada del mismo.
Si se recibe el mensaje SIP INVITE, el núcleo 403 de SIP puede reenviar el mensaje SIP INVITE al servidor 405 de MCPTT en la operación S420, y el servidor 405 de MCPTT puede realizar una comprobación de contexto con el servidor 407 de gestión de grupo de MCPTT y realizar la autenticación de autoridad en el mensaje SIP INVITE en la operación S430.
Si la información de modo de comienzo de servicio no está incluida en el mensaje SIP INVITE, el servidor 405 de MCPTT puede determinar el modo de comienzo de servicio basándose en el valor de configuración del usuario del UE.
Después de realizar la autenticación de autoridad, el servidor 405 de MCPTT puede enviar al primer UE 401 el mensaje SIP INVITE mediante el núcleo 403 de SIP en la operación S440.
Si se recibe el mensaje SIP INVITE, el primer UE 401 puede enviar en la operación S450 al segundo UE 409 un mensaje SIP 200 OK mediante el núcleo 403 de SIP y el servidor 405 de MCPTT para aceptar la solicitud de servicio unidireccional.
Si se recibe el mensaje SIP 200 OK, el segundo UE 409 envía al primer UE 401 un mensaje SIP ACK mediante el núcleo 403 de SIP y el servidor 405 de MCPTT para completar el comienzo de servicio en la operación S460. En este momento, los mensajes SIP 200 OK y ACK se transmiten a través de la misma ruta que el mensaje SIP INVITE. En la operación S470, se establece una sesión de medios.
La Figura 5 es un diagrama de flujo de señal que ilustra un procedimiento para un UE que está proporcionando un servicio unidireccional para iniciar un nuevo servicio unidireccional tras la recepción de una solicitud de servicio unidireccional de otro UE de acuerdo con una realización de la presente divulgación.
Haciendo referencia a la Figura 5, el primer UE 501 proporciona al segundo UE 508 con un servicio unidireccional (en lo sucesivo, el servicio unidireccional en curso se denomina de manera intercambiable como primer servicio unidireccional) en la operación S510.
En este momento, un tercer UE 509 puede enviar en la operación S520 al núcleo 503 de SIP un mensaje SIP INVITE para solicitar un servicio unidireccional (en lo sucesivo, el servicio unidireccional solicitado por el tercer UE se denomina de manera intercambiable como segundo servicio unidireccional).
Si se recibe el mensaje SIP INVITE, el núcleo 503 de SIP puede reenviar el mensaje SIP INVITE al servidor 505 de MCPTT en la operación S530, y el servidor 505 de MCPTT puede realizar una comprobación de contexto con el servidor 507 de gestión de grupo de MCPTT y realizar la autenticación de autoridad en el tercer UE 509 en la operación S540.
En este momento, el servidor 505 de MCPTT puede determinar si el tercer UE 509 tiene la capacidad de servicio unidireccional en el procedimiento de autenticación de autoridad. El servidor 505 de MCPTT puede comparar las
prioridades del primer y segundo servicios unidireccionales en el procedimiento de autenticación de autoridad. En este momento, el servidor 505 de MCPTT puede conocer prioridades específicas de servicio.
Como un resultado de comparación, si la prioridad del segundo servicio unidireccional es superior a la del primer servicio unidireccional, el servidor 505 de MCPTT puede realizar operaciones sucesivas para proporcionar el segundo servicio unidireccional.
De otra manera, si la prioridad del segundo servicio unidireccional no es superior a la del primer servicio unidireccional, el servidor 505 de MCPTT puede ignorar la solicitud de servicio unidireccional del tercer UE 509.
La Figura 5 se representa bajo la suposición de que la prioridad del segundo servicio unidireccional es superior a la del primer servicio unidireccional. Por consiguiente, el servidor 505 de MCPTT envía al primer UE 501 el mensaje SIP INVITE mediante el núcleo 503 de SIP en la operación S550.
Si se recibe el mensaje SIP INVITE, el primer UE 501 puede enviar al tercer UE 509 un mensaje SIP 200 OK mediante el núcleo 503 de SIP y el servidor 505 de MCPTT en la operación S560.
Si se recibe el mensaje SIP 200 OK, el tercer UE 509 puede enviar al primer UE 501 un mensaje SIP ACK mediante el núcleo 503 de SIP y el servidor 505 de MCPTT en la operación S570.
Posteriormente, el primer y tercer UE 501 y 509 establecen una sesión en la operación S580.
A continuación, el primer UE 501 puede enviar al segundo UE 508 un mensaje de fin (en lo sucesivo, denominado como mensaje SIP BYE) para liberar el primer servicio unidireccional en la operación S590.
Si se recibe el mensaje SIP BYE, el segundo UE 508 puede enviar al primer UE 501 el mensaje SIP 200 OK mediante el núcleo 503 de SIP y el servidor 505 de MCPTT en la operación S591, y el primer y segundo UE 501 y 508 pueden liberar la sesión previamente establecida en las operaciones S592 y S593.
Mientras tanto, el primer servicio unidireccional puede liberarse por el servidor 505 de MCPTT así como el primer UE 501.
La Figura 6 es un diagrama de flujo de señal que ilustra un procedimiento para que un servidor de MCPTT libere un servicio unidireccional en curso de acuerdo con una realización de la presente divulgación.
Haciendo referencia a la Figura 6, el primer UE 601 puede recibir un mensaje que solicita el segundo servicio unidireccional como un nuevo servicio unidireccional del tercer UE 611 durante la primera sesión de servicio unidireccional en la operación S610.
Puesto que el segundo procedimiento de implementación de servicio unidireccional es idéntico con las operaciones S520 a S580 de la Figura 5, se omite en el presente documento una descripción detallada de las operaciones S620 a S670.
Una vez que se establece una sesión entre el primer y tercer UE 601 y 611 en la operación S680 a través del procedimiento anterior, debe liberarse el primer servicio unidireccional establecido entre el primer y segundo UE 601 y 609.
Para este fin, el servidor 605 de MCPTT puede enviar al primer y segundo UE 601 y 609 un mensaje SIP BYE para solicitar la liberación del servicio unidireccional en la operación S690.
En respuesta al mensaje SIP BYE, el primer UE 601 puede enviar al servidor 605 de MCPTT un mensaje SIP 200 OK mediante el núcleo 603 de SIP en la operación S691.
En respuesta al mensaje SIP BYE, el segundo UE 609 puede enviar al servidor 605 de MCPTT un mensaje SIP 200 OK mediante el núcleo 603 de SIP en la operación 692.
Si se recibe el mensaje SIP 200 OK, el primer y segundo UE 601 y 609 pueden liberar la sesión en curso en las operaciones S693 y S694.
Aunque las Figuras 5 y 6 se refieren al caso donde el primer UE recibe un mensaje que solicita un nuevo servicio unidireccional de un nuevo UE y acepta la solicitud, el primer UE puede rechazar la nueva solicitud de servicio unidireccional. Se realiza una descripción detallada de lo mismo con referencia a la Figura 7.
La Figura 7 es un diagrama de flujo de señal que ilustra un procedimiento para rechazar una solicitud de nuevo servicio unidireccional de un nuevo UE de acuerdo con una realización de la presente divulgación.
Haciendo referencia a la Figura 7, el primer UE 701 puede estar proporcionando al segundo UE 709 con un servicio unidireccional (en lo sucesivo, denominado como un primer servicio unidireccional) en la operación S710.
Para solicitar un nuevo servicio unidireccional (en lo sucesivo, denominado como un segundo servicio unidireccional),
el tercer UE 711 puede enviar al núcleo 703 de SIP un mensaje SIP INVITE en la operación S720.
Si se recibe el mensaje SIP INVITE, el núcleo 703 de SIP puede reenviar el mensaje SIP INVITE al servidor 705 de MCPTT en la operación S730, y el servidor 705 de MCPTT puede realizar una comprobación de contexto con el servidor 707 de gestión de grupo de MCPTT y realizar la autenticación de autoridad en el tercer UE 711 en la operación S740.
Es decir, el servidor 705 de MCPTT puede realizar la autenticación de autoridad para determinar si el tercer UE 711 tiene la capacidad de servicio unidireccional y está suscrito al servicio unidireccional.
El servidor 705 de MCPTT puede comparar la prioridad del primer servicio unidireccional que se proporciona actualmente y la prioridad del segundo servicio unidireccional solicitado por el tercer UE 711 en el procedimiento de autenticación de autoría. En este momento, el servidor 705 de MCPTT puede conocer las propiedades específicas de servicio.
Como un resultado de comparación, si se determina que la prioridad del segundo servicio unidireccional es superior a la del primer servicio unidireccional, el servidor 705 de MCPTT puede realizar la operación sucesiva para proporcionar el segundo servicio unidireccional.
De otra manera, si se determina que la prioridad del segundo servicio unidireccional no es superior a la del primer servicio unidireccional, el servidor 705 de MCPTT puede ignorar o rechazar la solicitud de servicio unidireccional del tercer UE 711.
La Figura 7 se representa bajo la suposición de que la prioridad del segundo servicio unidireccional es superior a la del primer servicio unidireccional. Por consiguiente, el servidor 705 de MCPTT envía al primer UE 701 el mensaje SIP INVITE mediante el núcleo 703 de SIP en la operación 750.
Si se recibe el mensaje SIP INVITE, el primer UE 701 puede determinar si aceptar la segunda solicitud de servicio unidireccional. En este momento, el primer UE 701 puede determinar si aceptar la segunda solicitud de servicio unidireccional basándose en la prioridad del segundo servicio unidireccional solicitado por el tercer UE 711, en la preferencia de usuario, y en la información de estado de usuario actual.
Si se determina rechazar el segundo servicio unidireccional, el primer UE 701 puede enviar al tercer UE 711 un mensaje de rechazo mediante el núcleo 703 de SIP y el servidor 705 de MCPTT en la operación S760.
En este momento, el mensaje de rechazo puede ser un mensaje SIP, por ejemplo, mensaje de error SIP 4xx.
En respuesta al mensaje de rechazo, el tercer UE 711 puede enviar al primer UE 701 un mensaje ACK mediante el núcleo 703 de SIP y el servidor 705 de MCPTT en la operación S770.
La segunda solicitud de servicio unidireccional puede rechazarse por el servidor 705 de MCPTT así como el primer UE 701, y se realiza una descripción del mismo con referencia a la Figura 8.
La Figura 8 es un diagrama de flujo de señal que ilustra un procedimiento para que un servidor de MCPTT rechace una solicitud de servicio unidireccional de un UE de acuerdo con una realización de la presente divulgación.
Haciendo referencia a la Figura 8, el primer UE 801 puede estar proporcionando al segundo UE 809 con el primer servicio unidireccional en la operación S810.
En este momento, el tercer UE 811 puede enviar al núcleo 803 de SIP un mensaje SIP INVITE para solicitar el segundo servicio unidireccional en la operación S820.
El núcleo 803 de SIP puede reenviar el mensaje SIP INVITE al servidor 805 de MCPTT en la operación S830, y el servidor 805 de MCPTt puede realizar una comprobación de contexto con el servidor 807 de gestión de grupo de MCPTT y realizar la autenticación de autoridad en el tercer UE 811 en la operación S840.
En el procedimiento de autenticación de autoría, el servidor 805 de MCPTT puede determinar si el tercer UE 811 tiene la capacidad de servicio unidireccional. El servidor 805 de MCPTT puede determinar si aceptar la segunda solicitud de servicio unidireccional basándose en la prioridad del segundo servicio unidireccional solicitado por el tercer UE 811, en la preferencia de usuario, y en la información de estado de usuario actual.
Si se determina rechazar la segunda solicitud de servicio unidireccional puesto que la prioridad del segundo servicio unidireccional es inferior a la prioridad del primer servicio unidireccional o en consideración de preferencia de usuario y estado de usuario actual, el servidor 805 de MCPTT puede enviar al tercer UE 811 un mensaje de rechazo para rechazar la segunda solicitud de servicio unidireccional mediante el núcleo 803 de SIP en la operación S850.
En respuesta al mensaje de rechazo, el tercer UE 811 puede enviar al servidor 805 de MCPTT un mensaje ACK mediante el núcleo 803 de SIP en la operación S860.
Los procedimientos de las Figuras 5 a 8 se refieren a los casos donde un UE recibe una solicitud de servicio unidireccional de otro UE durante la sesión de servicio unidireccional en curso. Puede ser posible también que el UE reciba una solicitud para un nuevo servicio que no es el servicio unidireccional de otro UE durante el servicio unidireccional en curso.
La operación del UE que recibe la nueva solicitud de servicio de otro UE se describe con referencia a las Figuras 9A y 9B en lo sucesivo.
Las Figuras 9A y 9B son un diagrama de flujo de señal que ilustra un procedimiento de aceptación de una solicitud de servicio recibida durante un servicio unidireccional en curso de acuerdo con diversas realizaciones de la presente divulgación.
Haciendo referencia a la Figura 9A, el primer UE 901 puede estar proporcionando al segundo UE 911 con un servicio unidireccional en la operación S910.
El tercer UE 913 puede enviar al núcleo 903 de SIP un mensaje SIP INVITE para solicitar al primer UE 901 un nuevo servicio en la operación S920.
Tras la recepción del mensaje SIP INVITE, el núcleo 903 de SIP reenvía el mensaje SIP INVITE al AS 909 en la operación S930.
El núcleo 903 de SIP transmite el mensaje SIP INVITE al AS 909 en lugar de al servidor 905 de MCPTT puesto que el servicio solicitado por el tercer UE 913 no es servicio unidireccional.
Tras la recepción del mensaje SIP INVITE, el AS 909 puede realizar la autenticación de autoridad en el tercer UE 913 en la operación S940. En este momento, el AS 909 puede comparar la prioridad del servicio unidireccional en curso y la prioridad del nuevo servicio solicitado por el tercer UE 913.
Si se determina que la prioridad del nuevo servicio es superior a la prioridad del servicio unidireccional en curso, el AS 909 puede reenviar el mensaje SIP INVITE al primer UE 901 mediante el núcleo 903 de SIP en la operación S950. En respuesta al mensaje SIP INVITE, el primer UE 901 puede enviar al tercer UE 913 un mensaje SIP 200 OK mediante el núcleo 903 de SIP y el AS 909 en la operación S960.
Si se recibe el mensaje SIP 200 OK, el tercer UE 913 puede enviar al primer UE 901 un mensaje ACK mediante el núcleo 903 de SIP y el servidor 909 de AS en la operación S970 y finalizar el procedimiento de comienzo de servicio. Como consecuencia, el primer y tercer UE 901 y 913 establecen una sesión en la operación S980.
Posteriormente, el primer UE 901 envía al segundo UE 911 un mensaje de fin de sesión (mensaje SIP BYE) mediante el núcleo 903 de s Ip y servidor 905 de MCPTT para liberar el servicio unidireccional en curso en la operación S990. En respuesta al mensaje SIP BYE, el segundo UE 911 puede enviar al primer UE 901 un mensaje SIP 200 OK mediante el núcleo 903 de SIP y el servidor 905 de MCPTT en la operación S991, y el primer y segundo UE 901 y 911 pueden liberar la sesión antigua en las operaciones S992 y S993.
Las Figuras 9A y 9B muestran un procedimiento de aceptación de una nueva solicitud de servicio del tercer UE 913. El primer UE 901 puede rechazar también la solicitud de nuevo servicio del tercer UE 913 y se realiza una descripción detallada del mismo con referencia a la Figura 10.
La Figura 10 es un procedimiento para rechazar una solicitud de servicio durante un servicio unidireccional en curso de acuerdo con una realización de la presente divulgación.
Haciendo referencia a la Figura 10, el primer UE 1001 puede estar proporcionando al segundo UE 1011 con un servicio unidireccional en la operación S1010.
El tercer UE 1013 puede enviar al núcleo 1003 de SIP un mensaje SIP INVITE para solicitar al primer UE 1001 un nuevo servicio en la operación S1020.
Tras la recepción del mensaje SIP INVITE, el núcleo 1003 de SIP reenvía el mensaje SIP INVITE al AS 1009 en la operación S1030.
El núcleo 1003 de SIP transmite el mensaje SIP INVITE al servidor 1005 de MCPTT puesto que el servicio solicitado por el tercer UE 1013 no es un servicio unidireccional.
Tras la recepción del mensaje SIP INVITE, el AS 1009 puede realizar la autenticación de autoridad en el tercer UE 1013 en la operación S1040. En este momento, el AS 1009 puede comparar la prioridad del servicio unidireccional en curso y la prioridad del nuevo servicio solicitado por el tercer UE 1013.
Si se determina que la prioridad del nuevo servicio es superior que el del servicio unidireccional en curso, el AS 1009
puede reenviar el mensaje SIP INVITE al primer UE 1001 mediante el núcleo 1003 de SIP en la operación S1050.
Si se recibe el mensaje SIP INVITE, el primer UE 1001 puede determinar si aceptar la nueva solicitud de servicio realizada por el tercer UE 1013. En este momento, el primer UE 1001 puede determinar si aceptar la nueva solicitud de servicio basándose en la prioridad del nuevo servicio solicitado por el tercer UE 1013, en la preferencia de usuario, y en la información de estado de usuario actual.
Si se determina rechazar la nueva solicitud de servicio, el primer UE 1001 puede enviar al tercer UE 1013 un mensaje de rechazo mediante el núcleo 1003 de SIP y el AS 1009 en la operación S1060. El mensaje de rechazo puede ser un mensaje de SIP, por ejemplo, el mensaje de error SIP 4xx.
Tras la recepción del mensaje de rechazo, el tercer UE 1013 puede enviar al primer UE 1001 el mensaje de ACK mediante el núcleo 1003 de SIP y el servidor 1009 de AS en la operación S1070.
Las Figuras 11A y 11B son un diagrama de flujo de señal que ilustra un procedimiento para que un servidor de MCPTT libere un servicio unidireccional en curso entre dos UE tras la recepción de una nueva solicitud de servicio realizada por otro UE de acuerdo con diversas realizaciones de la presente divulgación.
Puesto que el servidor de MCPTT es responsable del servicio unidireccional y el AS es responsable de otros tipos de servicios, si el tercer UE solicita un nuevo servicio durante el servicio unidireccional entre el primer y segundo UE, el servidor de MCPTT no puede reconocer la recepción de la nueva solicitud de servicio en el primer UE. Puesto que el servidor de MCPTT no puede comprobar la sesión establecida entre el primer y tercer UE que se activa por la nueva solicitud de servicio realizada por el tercer UE, no puede conocer la necesidad de liberación del servicio unidireccional en curso. Por consiguiente, para liberar el servicio unidireccional en curso, el primer UE transmite el mensaje SIP BYE.
Las Figuras 11A y 11B se refieren a un procedimiento para el servidor de MCPTT para liberar el servicio unidireccional en curso cuando se establece una sesión entre el primer y tercer UE además del servicio unidireccional en curso compartiendo la información en los UE a través de un acuerdo de nivel de aplicación entre el servidor de MCPTT y AS de acuerdo con diversas realizaciones de la presente divulgación.
Haciendo referencia a las Figuras 11A y 11B, se realiza un acuerdo de nivel de aplicación entre el servidor 1105 de MCPTT y el AS 1109.
El primer UE 1101 puede estar proporcionando al segundo UE 1111 con un servicio unidireccional en la operación S1110.
El tercer UE 1113 puede enviar al núcleo 1103 de SIP un mensaje SIP INVITE para realizar une nueva solicitud al primer UE 1101 en la operación S1120.
El núcleo 1103 de SIP puede reenviar el mensaje SIP INVITE al AS en la operación S1130.
En este momento, el núcleo 1103 de SIP reenvía el mensaje SIP INVITE al AS 1109 en lugar de al servidor 1105 de MCPTT puesto que el servicio solicitado por el tercer UE 1113 no es un servicio universal.
Tras la recepción del mensaje SIP INVITE, el AS 1109 puede realizar la autenticación de autoridad en el tercer UE 1113 en la operación S1140. En este momento, el AS 1109 puede comparar la prioridad del servicio unidireccional en curso establecido con el segundo UE 1111 y la prioridad del nuevo servicio solicitado por el tercer UE 1113.
Si se determina que la prioridad del nuevo servicio es superior que el del servicio unidireccional en curso, el AS 1109 puede reenviar el mensaje SIP INVITE al primer UE 1101 mediante el núcleo 1103 de SIP en la operación S1150.
En respuesta al mensaje SIP INVITE, el primer UE 1101 puede enviar al tercer UE 1113 un mensaje SIP 200 OK mediante el núcleo 1103 de SIP y el AS 1109 en la operación S1160.
Tras la recepción del mensaje SIP 200 OK, el tercer UE 1113 puede enviar al primer UE 1101 un mensaje ACK mediante el núcleo 1103 de SIP y el AS 1109 en la operación S1170 para completar el procedimiento de comienzo de servicio.
Como consecuencia, se establece una sesión entre el primer y tercer UE 1101 y 1113 en la operación S1180.
Puesto que se realiza el acuerdo de nivel de aplicación entre el servidor 1105 de MCPTT y el AS 1109, el servidor 1105 de MCPTT puede tener conocimiento de la sesión establecida entre el primer y tercer UE 1101 y 1113. Por consiguiente, el servidor 1105 de MCPTT puede transmitir un mensaje SIP BYE al primer y segundo UE 1101 y 1111 mediante el núcleo 1103 de SIP para liberar el servicio unidireccional en curso entre el primer y segundo UE 1101 y 1111 en la operación S1190.
En respuesta al mensaje SIP BYE, el primer UE 1101 puede enviar al servidor 1105 de MCPTT un mensaje SIP 200 OK mediante el núcleo 1103 de SIP en la operación S1191. Análogamente, en respuesta al mensaje SIP BYE, el segundo UE 1111 puede enviar al servidor 1105 de MCPTT un mensaje SIP 200 OK en la operación S1192.
Posteriormente, el primer y segundo UE 1101 y 1111 pueden liberar la sesión establecida entre los mismos en las operaciones S1193 y S1194.
Las Figuras 12A y 12B son un diagrama de flujo de señal que ilustra un procedimiento para que un servidor de MCPTT libere un servicio en curso establecido entre un primer y un segundo UE tras la recepción de una nueva solicitud de servicio de un tercer UE de acuerdo con diversas realizaciones de la presente divulgación.
A diferencia de la realización de las Figuras 11A y 11B en las que el servidor de MCPTT y el AS comparten la información en el primer UE a través de un acuerdo de nivel de aplicación, el servidor de MCPTT realiza una solicitud de suscripción de evento al núcleo de SIP para obtener la información en el primer UE. Se realiza una descripción de un procedimiento para liberar el servicio unidireccional en curso establecido entre el primer y segundo UE tras la detección de una nueva sesión de servicio establecida entre el primer y tercer UE.
Haciendo referencia a las Figuras 12A y 12B, el servidor 1205 de MCPTT puede enviar al núcleo 1203 de SIP un mensaje SIP SUBSCRIBE en la operación S1210 y recibir un mensaje SIP 200 OK en respuesta al mensaje SIP SUBSCRIBE en la operación S1220.
Sin embargo, la transmisión de mensaje SIP SUBSCRIBE no está limitada a la temporización como se representa en el dibujo.
El primer UE 1201 puede estar proporcionando al segundo UE 1211 un servicio unidireccional en la operación S1230.
El tercer UE 1213 puede enviar al núcleo 1203 de SIP un mensaje SIP INVITE para realizar una nueva solicitud de servicio al primer UE 1201 en la operación S1240.
El núcleo 1203 de SIP reenvía el mensaje SIP INVITE al AS 1209 en la operación S1250.
El núcleo 1203 de SIP puede enviar al servidor 1205 de MCPTT un mensaje SIP NOTIFY para notificar que el tercer UE 1213 ha realizado una nueva solicitud de servicio en la operación S1260.
Tras la recepción del mensaje SIP INVITE, el AS 1209 puede realizar la autenticación de autoridad en el tercer UE 1213 en la operación S1270. En este momento, el AS 1209 puede comparar la prioridad del servicio unidireccional en curso y la prioridad del nuevo servicio solicitado por el tercer UE 1213.
Si se determina que la prioridad del nuevo servicio solicitado por el tercer UE 1213 es superior a la del servicio unidireccional en curso, el AS 1209 puede reenviar el mensaje SIP INVITE al primer UE 1201 mediante el núcleo 1203 de SIP en la operación S1275.
En respuesta al mensaje SIP INVITE, el primer UE 1201 puede enviar al tercer UE 1213 un mensaje SIP 200 OK mediante el núcleo 1203 de SIP y el AS 1209 en la operación S1280.
Tras la recepción del mensaje SIP 200 OK, el tercer UE 1213 puede enviar al primer UE 1201 un mensaje SIP ACK mediante el núcleo 1203 de SIP y el AS 1209 para completar el procedimiento de comienzo de servicio en la operación S1285.
Como consecuencia, se establece una sesión entre el primer y tercer UE 1201 y 1213 en la operación S1290.
El núcleo 1203 de SIP puede enviar al servidor 1205 de MCPTT un mensaje SIP NOTIFY para notificar que se ha establecido una sesión entre el primer y tercer UE 1201 y 1213 en la operación S1291.
El servidor 1205 de MCPTT tiene conocimiento de la sesión establecida entre el primer y tercer UE 1201 y 1213 tras la recepción del mensaje SIP NOTIFY. A continuación el servidor 1205 de MCPTT puede enviar al primer y segundo UE 1201 y 1211 un mensaje SIP BYE mediante el núcleo 1203 de SIP para liberar el servicio unidireccional en curso establecido entre el primer y segundo UE 1201 y 1211 en la operación S1292.
En respuesta al mensaje SIP BYE, el primer UE 1201 envía al servidor 1205 de MCPTT un mensaje SIP 200 OK mediante el núcleo 1203 de SIP en la operación S1293. Análogamente, en respuesta al mensaje SIP BYE, el segundo UE 1211 envía al servidor 1205 de MCPTT el mensaje SIP 200 OK mediante el núcleo 1203 de SIP en la operación S1294.
A continuación el primer y segundo UE 1201 y 1211 pueden liberar la sesión establecida entre los mismos en las operaciones S1295 y S1296.
A diferencia de las realizaciones de las Figuras 11A y 11B y las Figuras 12A y 12B, el UE puede recibir una solicitud de servicio unidireccional durante un servicio no unidireccional en curso. Incluso en este caso, el UE puede determinar si aceptar la solicitud de servicio unidireccional basándose en las prioridades del servicio unidireccional solicitado y el servicio en curso, en la preferencia de usuario, y en el estado de usuario actual.
Puede determinarse si aceptar la solicitud de servicio unidireccional por el servidor de MCPTT. El servidor de MCPTT
puede tener conocimiento de que el UE que ha recibido la solicitud de servicio unidireccional está recibiendo otro servicio a través del acuerdo de nivel de aplicación con el AS o suscripción de evento al núcleo de SIP. Por consiguiente, el servidor de MCPTT puede determinar si aceptar la solicitud de servicio unidireccional basándose en las prioridades del servicio unidireccional solicitado y el servicio en curso, en la preferencia de usuario, y en el estado de usuario actual.
La Figura 13 es un diagrama de flujo de señal que ilustra un procedimiento para que un UE libere un servicio unidireccional en curso de acuerdo con una realización de la presente divulgación.
Haciendo referencia a la Figura 13, el primer UE 1301 en una sesión de servicio unidireccional puede determinar si liberar el servicio unidireccional en la operación S1310. Por ejemplo, el primer UE 1301 puede determinar liberar el servicio unidireccional cuando se resuelve la situación de emergencia o se solicita un servicio de prioridad superior.
Si se determina liberar el servicio unidireccional, el UE 1301 puede enviar al núcleo 1303 de SIP un mensaje SIP BYE para liberar el servicio unidireccional en la operación S1320. El núcleo 1303 de SIP puede reenviar el mensaje SIP BYE al servidor 1305 de MCPTT en la operación S1330.
Tras la recepción del mensaje SIP BYE, el servidor 1305 de MCPTT puede realizar la autenticación de autoridad para determinar si el primer UE 1301 tiene un derecho a liberar el servicio unidireccional en la operación S1340.
El procedimiento de liberación de servicio unidireccional se realiza de manera diferente dependiendo de la entidad que ha iniciado el servicio unidireccional. Si se inicia el servicio unidireccional por un UE, el servicio unidireccional puede liberarse por el UE, el gestor de servicio, o el servidor de MCPTT.
Si se inicia el servicio unidireccional por el gestor de servicio, el UE no puede liberar el correspondiente servicio unidireccional. Esto significa que únicamente el gestor de servicio y el servidor de MCPTT pueden liberar el correspondiente servicio. Si el UE intenta liberar el servicio unidireccional iniciado por el gestor de servicio, se transmite una solicitud de liberación al servidor de MCPTT mediante el núcleo de SIP y, en este momento, el servidor de MCPTT comprueba que el UE no tiene derecho a liberar el servicio unidireccional y por lo tanto rechaza la solicitud de liberación.
Si se recibe una solicitud de liberación de servicio unidireccional del UE o el gestor de servicio, el servidor de MCPTT determina si la entidad que ha solicitado la liberación de servicio unidireccional tiene el derecho a liberar el servicio unidireccional.
En el dibujo, se supone que el primer UE 1301 tiene el derecho a liberar el servicio unidireccional. Por consiguiente, el servidor 1305 de MCPTT comprueba el derecho de liberación de servicio del primer UE 1301 y envía al segundo UE 1307 un mensaje SIP BYE mediante el núcleo 1301 de SIP en la operación S1350.
En respuesta al mensaje SIP BYE, el segundo UE 1307 envía al primer UE 1301 un mensaje SIP 200 OK mediante el núcleo 1303 de SIP y el servidor 1305 de MCPTT en la operación S1360, y el primer y segundo UE 1301 y 1307 liberan la sesión de servicio unidireccional en las operaciones S1370 y S1380.
La Figura 14 es un diagrama de flujo de señal que ilustra un procedimiento para que un UE libere un servicio unidireccional usando un mensaje SIP re-INVITE en lugar de un mensaje SIP BYE de acuerdo con una realización de la presente divulgación.
Haciendo referencia a la Figura 14, como se describe con referencia a la Figura 13, el primer UE 1401 en una sesión de servicio unidireccional puede determinar si liberar el servicio unidireccional en la operación S1410.
Si se determina liberar el servicio unidireccional, el UE 1401 puede enviar al núcleo 1303 de SIP un mensaje SIP re INVITE en lugar del mensaje SIP BYE para liberar el servicio unidireccional en la operación S1420.
El primer UE 1401 puede bloquear la transmisión de datos en la sesión actual en lugar de liberar la sesión transmitiendo el mensaje SIP re-INVITE. En este momento, el primer UE 1401 puede establecer un SDP del mensaje SIP re-INVITE a a=inactive (inactivo) o a=rcvonly (únicamente recepción). Es decir, el primer UE 1401 puede establecer el SDP a un valor que indica la desactivación o recepción de sesión únicamente para bloquear el servicio unidireccional.
El núcleo 1403 de SIP puede reenviar el mensaje SIP re-INVITE al servidor 1405 de MCPTT en la operación S1430.
Tras la recepción del mensaje SIP re-INVITE, el servidor 1405 de MCPTT realiza autenticación de autoridad para determinar si el primer UE tiene el derecho a liberar el servicio unidireccional en la operación S1440.
Si se determina que el primer UE 1401 tiene el derecho a liberar el servicio unidireccional, el servidor 1405 de MCPTT envía al segundo UE 1407 un mensaje SIP re-INVITE mediante el núcleo 1403 de SIP en la operación S1450.
En respuesta al mensaje SIP re-INVITE, el segundo UE 1407 puede enviar al primer UE 1401 un mensaje SIP 200 OK mediante el núcleo 1403 de SIP y el servidor 1405 de MCPTT en la operación 1460, y el primer y segundo UE 1401 y 1407 pueden bloquear la transmisión de datos sin liberar la sesión en las operaciones S1470 y S1480.
A diferencia de las realizaciones de las Figuras 13 y 14, el servicio unidireccional puede liberarse por un gestor de servicio, y se realiza una descripción de lo mismo en lo sucesivo.
La Figura 15 es un diagrama de flujo de señal que ilustra un procedimiento para que un segundo UE libere un servicio unidireccional de acuerdo con una realización de la presente divulgación. En la Figura 15, el segundo UE 1507 puede incluir un gestor de servicio.
Haciendo referencia a la Figura 15, el segundo UE 1507 en una sesión de servicio unidireccional puede determinar si liberar el servicio unidireccional en la operación S1510.
Si se determina liberar el servicio unidireccional, el segundo UE 1507 puede enviar al núcleo 1503 de SIP un mensaje SIP re-INVITE para liberar el servicio unidireccional en la operación S1520. En este momento, el segundo UE 1507 puede establecer el SDP del mensaje SIP re-INVITE a a=inactive (inactivo) o a=rcvonly (únicamente recepción). Es decir, el segundo UE 1507 puede desactivar la sesión o permitir la recepción únicamente para suspender el servicio unidireccional.
El segundo UE 1507 puede enviar un mensaje SIP BYE en lugar del mensaje SIP re-INVITE.
El núcleo 1503 de SIP puede reenviar el mensaje SIP re-INVITE al servidor 1505 de MCPTT en la operación S1530.
Tras la recepción del mensaje SIP re-INVITE, el servidor 1505 de MCPTT realiza autenticación de autoridad para determinar si el segundo UE 1507 tiene el derecho a liberar el servicio unidireccional en la operación S1540.
Si se determina que el segundo UE 1507 tiene el derecho a liberar el servicio unidireccional, el servidor 1505 de MCPTT reenvía el mensaje SIP re-INVITE al primer UE 1501 mediante el núcleo 1503 de SIP en la operación S1550.
En respuesta al mensaje SIP re-INVITE, el primer UE 1501 puede enviar al segundo UE 1507 un mensaje SIP 200 OK mediante el núcleo 1503 de SIP y el servidor 1505 de MCPTT en la operación S1560, y el primer y segundo UE 1501 y 1507 pueden suspender la transmisión de datos sin liberar la sesión en la operación S1570 y S1580.
La Figura 16 es un diagrama de flujo de señal que ilustra un procedimiento para que un servidor de MCPTT libere el servicio unidireccional de acuerdo con una realización de la presente divulgación.
Haciendo referencia a la Figura 16, el servidor 1605 de MCPTT puede liberar el servicio unidireccional. El servidor 1605 de MCPTT puede determinar si liberar el servicio unidireccional y, si se determina liberar el servicio unidireccional, realizar autenticación de autoridad en la operación S1610.
Si se completa la autenticación de autoridad, el servidor 1605 de MCPTT puede enviar al primer y segundo UE 1601 y 1609 un mensaje SIP re-INVITE mediante el núcleo 1603 de SIP para liberar el servicio unidireccional en la operación S1620. En este momento, el servidor 1605 de MCPTT puede establecer el SDP del mensaje SIP re-INVITE a a=inactive (inactivo) o a=rcvonly (únicamente recepción). Es decir, el servidor 1605 de MCPTT puede desactivar la sesión o permitir la recepción usando únicamente el SDP. El servidor 1605 de MCPTT puede incluir una causa de la liberación de servicio unidireccional en el encabezado SIP.
El primer UE 1601 puede transmitir el mensaje SIP BYE en lugar del mensaje SIP re-INVITE.
En respuesta al mensaje SIP re-INVITE, el primer y segundo UE 1601 y 1609 pueden enviar al servidor 1605 de MCPTT un mensaje SIP 200 OK mediante el núcleo 1603 de SIP en la operación S1630.
El primer y segundo UE 1601 y 1609 pueden suspender la transmisión de datos sin liberar la sesión en las operaciones S1640 y S1650.
El servidor de MCPTT puede liberar la sesión usando el mensaje SIP BYE en lugar del mensaje SIP re-INVITE.
La Figura 17 es un diagrama de flujo de señal que ilustra un procedimiento para rechazo de una solicitud de liberación de servicio unidireccional realizada por un UE que no tiene derecho a liberar el servicio unidireccional de acuerdo con una realización de la presente divulgación.
Haciendo referencia a la Figura 17, el primer UE 1701 en una sesión de servicio unidireccional puede determinar liberar el servicio unidireccional en la operación S1710.
Si se determina liberar el servicio unidireccional, el primer UE 1701 puede enviar al núcleo 1703 de SIP un mensaje SIP BYE para liberar el servicio unidireccional en la operación S1720. El UE 1701 puede transmitir un mensaje SIP re-INVITE.
El núcleo 1303 de SIP reenvía el mensaje SIP BYE al servidor 1705 de MCPTT en la operación S1730.
Tras la recepción del mensaje SIP BYE, el servidor 1705 de MCPTT realiza autenticación de autoridad para determinar si el primer UE que ha realizado la solicitud de liberación de servicio unidireccional tiene el derecho a liberar el servicio unidireccional en la operación S1740.
Como se ha descrito anteriormente, el procedimiento de liberación de servicio unidireccional se realiza de manera diferente dependiendo de la entidad que ha iniciado el servicio unidireccional. Si se inicia el servicio unidireccional por un gestor de servicio, el UE no puede liberar el correspondiente servicio unidireccional. Esto significa que únicamente el gestor de servicio y el servidor de MCPTT pueden liberar el correspondiente servicio. Si el UE intenta liberar el servicio unidireccional iniciado por el gestor de servicio, se transmite una solicitud de liberación al servidor de MCPTT mediante el núcleo de SIP y, en este momento, el servidor de MCPTT comprueba que el UE no tiene derecho a liberar el servicio unidireccional y por lo tanto rechaza la solicitud de liberación.
En el dibujo, se supone que el primer UE 1701 no tiene derecho a liberar el servicio unidireccional. Por consiguiente, el servidor 1705 de MCPTT falla la autenticación de autoridad en la operación S1740 puesto que el primer UE 1701 no tiene derecho a liberar el servicio unidireccional. Si la autenticación de autoridad falla, el servidor 1705 de MCPTT puede enviar al primer UE 1701 un mensaje de rechazo mediante el núcleo 1703 de SIP en la operación S1750. El mensaje de rechazo puede ser un mensaje de error SIP 4xx.
Si se recibe el mensaje de rechazo, el primer UE 1701 puede enviar al servidor 1705 de MCPTT un mensaje SIP ACK que indica la recepción del mensaje de rechazo mediante el núcleo 1703 de SIP en la operación S1760.
En el caso de que el primer UE 1701 no tenga derecho a liberar el servicio unidireccional, puede controlar de manera que no se presente un botón de liberación de servicio unidireccional en su UI. Como consecuencia, el usuario no puede hacer una solicitud de liberación de servicio unidireccional por medio del primer UE.
En el caso de que el primer UE 1701 no tenga derecho a liberar el servicio unidireccional, es necesario evitar un estado de apagado del primer UE 1701 para evitar que se libere inintencionadamente el servicio unidireccional. Por consiguiente, el primer UE 1701 puede estar configurado para visualizar una pantalla que muestra como si el UE estuviera en un estado de apagado, incluso si este no es el caso real, cuando se presiona el botón de encendido.
Incluso en el caso donde la UI del primer UE 1701 presente un botón de liberación de servicio, el servidor 1705 de MCPTT puede determinar si el primer UE 1701 tiene el derecho a liberar el servicio unidireccional y, si no, rechazar la solicitud de liberación de servicio unidireccional del UE.
La Figura 18 es un diagrama de bloques que ilustra una configuración de un UE de acuerdo con una realización de la presente divulgación.
Haciendo referencia a la Figura 18, el UE puede incluir un transceptor 1810, un controlador (procesador) 1820, y una memoria 1830.
El transceptor 1810 es responsable de la comunicación con otras entidades de red. El transceptor 1810 puede comunicar mensajes con otras entidades de red para un servicio unidireccional.
El controlador 1820 puede transmitir un mensaje de registro para registrar el UE con un servidor de MCPTT. El controlador 1820 puede controlar el transceptor 1810 para transmitir un mensaje SIP INVITE para solicitar el servicio unidireccional. En este momento, el controlador 1820 puede generar el mensaje SIP INVITE que incluye la información en la información unidireccional.
El controlador 1820 puede establecer también un parámetro de modo de servicio a un valor que indica un comienzo de servicio manual para iniciar el servicio de acuerdo con una entrada de usuario o un comienzo de servicio automático para iniciar el servicio inmediatamente sin ninguna entrada de usuario.
El controlador 1820 puede transmitir un mensaje para liberar el servicio unidireccional en curso o un servicio no unidireccional (servicio normal).
El controlador 1820 puede recibir también un mensaje de respuesta en respuesta al mensaje de liberación. El controlador 1820 puede transmitir también un mensaje de respuesta en respuesta a un mensaje recibido.
El controlador 1820 puede establecer una sesión con el UE que ha solicitado el correspondiente servicio.
Si se establece una sesión con un nuevo UE, el controlador 1820 puede liberar el servicio en curso establecido con otro UE. Si el UE no tiene derecho a liberar el servicio unidireccional, el controlador 1820 puede controlar la UI para ocultar un botón de liberación de servicio unidireccional. A continuación el usuario no puede hacer una solicitud de liberación de servicio unidireccional.
Si el UE no tiene derecho a liberar el servicio unidireccional, el controlador 1820 puede controlar el UE para visualizar una pantalla que muestra como si el UE estuviera en un estado de apagado, incluso si este no es el caso real, cuando se presiona el botón de encendido.
La memoria 1830 puede almacenar la información para su uso al determinar si aceptar una solicitud de servicio. La memoria 1830 puede almacenar prioridades específicas de servicio e información de preferencia de usuario.
La Figura 19 es un diagrama de bloques que ilustra una configuración de un servidor de acuerdo con una realización
de la presente divulgación.
Haciendo referencia a la Figura 19, el servidor de acuerdo con una realización de la presente divulgación incluye un transceptor 1910, un controlador (procesador) 1920, y una memoria 1930.
El transceptor 1920 es responsable de la comunicación con otras entidades de red. En más detalle, el transceptor 1910 puede hacer posible que el servidor se comunique con un UE, un gestor de servicio, un núcleo de SIP, y un servidor de gestión de grupo.
El controlador 1920 puede realizar autenticación de autoridad en el UE que solicita un servicio. Es decir, el controlador 1920 puede determinar si el UE tiene una capacidad de servicio unidireccional y está suscrito al servicio de MCPTT. En el caso de que el mensaje transmitido por el UE incluya un valor de modo de comienzo de servicio, el controlador 1920 puede determinar si el UE tiene un derecho a configurar el modo de comienzo de servicio. Si el UE realiza una solicitud para liberar el servicio, el controlador 1920 puede determinar si el UE tiene un derecho a liberar el servicio. Si la autenticación de autoridad falla, el controlador 1920 puede transmitir un mensaje de rechazo.
Si se recibe una nueva solicitud de servicio, el controlador 1920 puede comparar la prioridad del servicio en curso y la prioridad del servicio nuevamente solicitado para determinar si reenviar la nueva solicitud de servicio al UE.
Si se determina proporcionar al nuevo UE con el servicio unidireccional o el servicio normal, el controlador 1920 puede controlar para liberar el servicio en curso.
El controlador 1920 puede reconocer si el servicio solicitado es un servicio normal y si la solicitud se acepta basándose en el acuerdo de nivel de aplicación y suscribir el intercambio de mensajes con el núcleo de SIP.
Si se determina liberar el servicio, el controlador 1920 puede transmitir un mensaje para liberar el servicio.
La memoria 1930 puede almacenar la información para su uso al realizar la autenticación de autoridad. Es decir, la memoria 1903 puede almacenar la información en los UE que tienen la capacidad de servicio unidireccional y/o la capacidad de configuración de modo de comienzo de servicio.
La memoria 1930 puede almacenar también información de prioridad específica de servicio, información de preferencia de usuario, e información de estado de usuario actual para su uso al determinar si aceptar una solicitud para un nuevo servicio.
Como se ha descrito anteriormente, el procedimiento y aparato de implementación de servicio de la presente divulgación son ventajosos en términos de obtención de contenido de medios en los alrededores del terminal en una situación de emergencia y la transmisión del contenido de medios a un gestor de situación de emergencia de manera eficaz.
Aunque se ha mostrado y descrito la presente divulgación con referencia a diversas realizaciones de la misma, se entenderá por los expertos en la materia que pueden realizarse en la misma diversos cambios en forma y detalles. El ámbito de protección se define por las reivindicaciones adjuntas.
Claims (7)
1. Un procedimiento por un primer terminal (201-1701) en un sistema de comunicación, comprendiendo el procedimiento:
registrar con un servidor (205-1705) transmitiendo un mensaje de registro al servidor (205-1705);
transmitir, en caso de que se active un primer servicio unidireccional basándose en un sensor del primer terminal, un primer mensaje de solicitud de servicio que incluye información que solicita el primer servicio unidireccional al servidor (205-1705);
recibir, de un segundo terminal (309, 409, 508, 609-809, 911-1211, 1307-1507, 1609, 1707), un mensaje de respuesta para aceptar el primer servicio unidireccional;
transmitir, al segundo terminal (309, 409, 508, 609-809, 911-1211, 1307-1507, 1609, 1707), un mensaje de acuse de recibo, ACK, para el mensaje de respuesta; y
establecer una primera sesión de medios para el primer servicio unidireccional con el segundo terminal (309, 409, 508, 609-809, 911-1211, 1307-1507, 1609, 1707), usándose únicamente la primera sesión de medios para que el primer terminal (201-1701) transmita datos,
en el que el primer mensaje de solicitud de servicio incluye un modo de comienzo de servicio que indica si una primera solicitud de servicio ha de aceptarse automática o manualmente y al menos uno de un subsistema multimedia de IP, IMS, un identificador de servicio de comunicación, ICSI, y un identificador de referencia de aplicación de IMS, IARI, que indica el primer servicio unidireccional.
2. El procedimiento de la reivindicación 1,
en el que el primer servicio unidireccional incluye un servicio que transmite un contenido de medios de una manera unidireccional.
3. El procedimiento de la reivindicación 1, que comprende adicionalmente:
recibir, de otro terminal (509, 611-811, 913-1213), un segundo mensaje de solicitud de servicio para solicitar un segundo servicio unidireccional; y
determinar si aceptar una segunda solicitud de servicio basándose en al menos una de información de prioridad de servicio o información de usuario.
4. El procedimiento de la reivindicación 3, que comprende adicionalmente:
en caso de que se acepte la segunda solicitud de servicio, transmitir un mensaje de liberación para liberar la primera sesión de medios y establecer una segunda sesión de medios con el otro terminal (509, 611-811, 913 1213); y
transmitir, en caso de que no se acepte la segunda solicitud de servicio, un mensaje de rechazo al otro terminal (509, 611-811, 913-1213) para rechazar la segunda solicitud de servicio.
5. Un primer terminal (201-1701) de un sistema de comunicación, comprendiendo el terminal (201-1701):
un transceptor; y
un controlador acoplado con el transceptor y configurado para:
registrar con un servidor (205-1705) transmitiendo un mensaje de registro al servidor (205-1705),
transmitir, en caso de que se active un primer servicio unidireccional basándose en un sensor del primer terminal, un primer mensaje de solicitud de servicio incluyendo información que solicita el primer servicio unidireccional al servidor (205-1705),
recibir, de un segundo terminal (309, 409, 508, 609-809, 911-1211, 1307-1507, 1609, 1707), un mensaje de respuesta para aceptar el primer servicio unidireccional,
transmitir, al segundo terminal (309, 409, 508, 609-809, 911-1211, 1307-1507, 1609, 1707), un mensaje de acuse de recibo, ACK, para el mensaje de respuesta, y
establecer una primera sesión de medios para el primer servicio unidireccional con el segundo terminal (309, 409, 508, 609-809, 911-1211, 1307-1507, 1609, 1707), usándose únicamente la primera sesión de medios para que el primer terminal (201-1701) transmita datos,
en el que el primer mensaje de solicitud de servicio incluye un modo de comienzo de servicio que indica si una primera solicitud de servicio ha de aceptarse automática o manualmente y al menos uno de un subsistema multimedia de IP, IMS, un identificador de servicio de comunicación, ICSI, , y un identificador de referencia de aplicación de IMS, IARI, que indica el primer servicio unidireccional.
6. El primer terminal (201-1701) de la reivindicación 5,
en el que el primer servicio unidireccional incluye un servicio que transmite un contenido de medios de una manera unidireccional.
7. El primer terminal (201-1701) de la reivindicación 5, en el que el controlador está configurado adicionalmente para:
recibir, de otro terminal (509, 611-811, 913-1213), un segundo mensaje de solicitud de servicio para solicitar un segundo servicio unidireccional,
determinar si aceptar una segunda solicitud de servicio basándose en al menos una de información de prioridad de servicio o información de usuario,
y, en caso de que se acepte la segunda solicitud de servicio, transmitir un mensaje de liberación para liberar la primera sesión de medios y
establecer una segunda sesión de medios con el otro terminal (509, 611-811,913-1213), y transmitir al otro terminal (509, 611-811, 913-1213), en caso de que no se acepte la segunda solicitud de servicio, un mensaje de rechazo para rechazar la segunda solicitud de servicio.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020150084485A KR102273533B1 (ko) | 2015-06-15 | 2015-06-15 | 무선 통신 시스템에서 서비스 제공 방법 및 장치 |
| PCT/KR2016/006361 WO2016204514A1 (en) | 2015-06-15 | 2016-06-15 | Service implementation method and apparatus in wireless communication system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2795435T3 true ES2795435T3 (es) | 2020-11-23 |
Family
ID=57517594
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES16811927T Active ES2795435T3 (es) | 2015-06-15 | 2016-06-15 | Procedimiento y aparato de implementación de servicio en sistema de comunicación inalámbrica |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US10237704B2 (es) |
| EP (1) | EP3308560B1 (es) |
| KR (1) | KR102273533B1 (es) |
| CN (1) | CN107736040B (es) |
| ES (1) | ES2795435T3 (es) |
| WO (1) | WO2016204514A1 (es) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9980118B1 (en) | 2017-04-28 | 2018-05-22 | Motorola Solutions, Inc. | Intelligent ambience listening target selection with multiple concurrent devices |
| GB2572703B (en) * | 2016-12-19 | 2022-01-19 | Motorola Solutions Inc | Intelligent ambience listening target selection with multiple concurrent devices |
| EP3613226B1 (en) * | 2017-05-15 | 2022-09-28 | Samsung Electronics Co., Ltd. | Method and system for notifying state of members of mission critical service (mcx) groups |
| US10638524B2 (en) | 2017-07-31 | 2020-04-28 | Samsung Electronics Co., Ltd. | Method and system for providing mission critical service (MCX) in wireless communication network |
| US11128673B2 (en) * | 2017-08-04 | 2021-09-21 | Blackberry Limited | Method and system for access and use of multiple ISIM or ISIM credentials |
| CN110999397B (zh) * | 2017-08-11 | 2022-04-29 | 华为技术有限公司 | 一种设备发现方法及相关设备 |
| CN109874114B (zh) * | 2019-01-07 | 2020-09-15 | 北京交通大学 | 一种基于mcptt的集群系统预先建立会话方法 |
| JP2022548186A (ja) * | 2019-08-12 | 2022-11-17 | オッポ広東移動通信有限公司 | セッション確立方法及び装置 |
| US12598225B2 (en) * | 2020-10-13 | 2026-04-07 | Samsung Electronics Co., Ltd. | Method and apparatus for sharing sensor information on a call |
Family Cites Families (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6974072B2 (en) * | 2003-02-22 | 2005-12-13 | Graphic Packaging International, Inc. | Paperboard carton with a new type of dispenser |
| GB0319359D0 (en) | 2003-08-18 | 2003-09-17 | Nokia Corp | Activation of communication sessions in a communication system |
| NZ547178A (en) * | 2003-11-20 | 2008-06-30 | Alteragon Pty Ltd | Method of decreasing fat deposits and body weight in mammals and birdsusing the R-isomer of Salbutamol |
| DE602004028213D1 (de) * | 2004-03-05 | 2010-09-02 | T Mobile Deutschland Gmbh | Verfahren zum Registrieren eines Kommunikationsendgeräts in einem IMS-Dienstnetz |
| CN101027926B (zh) * | 2004-09-21 | 2012-11-14 | 艾利森电话股份有限公司 | 提供无线一键通(PoC)动态业务选项的设备和方法 |
| KR100666984B1 (ko) * | 2004-09-24 | 2007-01-10 | 삼성전자주식회사 | 푸쉬 투 토크 오버 셀룰러 시스템 사용자의 응답 모드에따른 호 처리 시스템 및 방법 |
| US7477911B1 (en) | 2004-12-16 | 2009-01-13 | Cellco Partnership | Method and system for facilitating a power-on registration for use with a wireless push to talk system |
| US20060168640A1 (en) * | 2005-01-26 | 2006-07-27 | Akseli Anttila | Media device and enhancing use of media device |
| KR101174525B1 (ko) * | 2005-03-08 | 2012-08-16 | 삼성전자주식회사 | 푸쉬투토크 오버 셀룰러 네트워크의 응답 클라이언트 식별방법 및 그 시스템 |
| KR101196123B1 (ko) * | 2005-04-04 | 2012-10-31 | 텔레폰악티에볼라겟엘엠에릭슨(펍) | 푸쉬-투-토크 모바일 통신 서비스에서의 응답 모드 |
| US20070002779A1 (en) * | 2005-06-15 | 2007-01-04 | Samsung Electronics Co., Ltd. | Method and system for providing PTT to conference |
| CN100450222C (zh) * | 2005-07-15 | 2009-01-07 | 华为技术有限公司 | 在会话中被邀请用户获取群组信息的方法及装置 |
| DK1781053T3 (da) * | 2005-10-28 | 2012-08-13 | Ericsson Telefon Ab L M | Fremgangsmåder og apparat til tjeneste af typen push-to-talk |
| US8463307B1 (en) * | 2005-11-28 | 2013-06-11 | Sprint Spectrum L.P. | Method of requesting a communication session using segmented signaling messages |
| US7558587B2 (en) * | 2005-12-12 | 2009-07-07 | Motorola, Inc. | System and method for dynamically selecting wireless information communication modes for a wireless communication device |
| KR100790716B1 (ko) * | 2006-07-25 | 2008-01-02 | 삼성전기주식회사 | 초소형 촬상 광학계 |
| KR20080013684A (ko) * | 2006-08-09 | 2008-02-13 | 엘지전자 주식회사 | Pt 서비스의 자동 응답 모드에서의 프라이버시 확보 방법 |
| US8676242B2 (en) * | 2007-02-16 | 2014-03-18 | Qualcomm Incorporated | Method and apparatus for registration of location information of wireless devices in a wireless communication network supporting multicast calls |
| US7769404B1 (en) * | 2007-05-02 | 2010-08-03 | Nextel Communications Inc. | Guaranteed talk permit with forced audio in a dispatch communication network |
| KR100998583B1 (ko) | 2008-03-27 | 2010-12-07 | 삼성전자주식회사 | 디지털 방송 서비스 방법 및 시스템 |
| US20100025746A1 (en) * | 2008-07-31 | 2010-02-04 | Micron Technology, Inc. | Methods, structures and systems for interconnect structures in an imager sensor device |
| US8675553B2 (en) * | 2009-03-26 | 2014-03-18 | Qualcomm Incorporated | Regulating the scope of service geographically in wireless networks based on priority |
| US8938498B2 (en) * | 2009-04-03 | 2015-01-20 | Qualcomm Incorporated | Uninterruptable group communication sessions within a wireless communications system |
| WO2014089576A1 (en) * | 2012-12-07 | 2014-06-12 | Chamtech Technologies Incorporated | Techniques for biometric authentication of user of mobile device |
| US9661144B2 (en) * | 2013-09-13 | 2017-05-23 | Motorola Solutions, Inc. | Method and apparatus for priority summing of group auditory data |
| US10079822B2 (en) * | 2014-06-30 | 2018-09-18 | Intel IP Corporation | Techniques for securely receiving critical communication content associated with a critical communication service |
-
2015
- 2015-06-15 KR KR1020150084485A patent/KR102273533B1/ko active Active
-
2016
- 2016-06-10 US US15/179,429 patent/US10237704B2/en active Active
- 2016-06-15 WO PCT/KR2016/006361 patent/WO2016204514A1/en not_active Ceased
- 2016-06-15 ES ES16811927T patent/ES2795435T3/es active Active
- 2016-06-15 EP EP16811927.9A patent/EP3308560B1/en active Active
- 2016-06-15 CN CN201680034568.2A patent/CN107736040B/zh active Active
Also Published As
| Publication number | Publication date |
|---|---|
| EP3308560B1 (en) | 2020-05-06 |
| WO2016204514A1 (en) | 2016-12-22 |
| CN107736040B (zh) | 2021-06-25 |
| EP3308560A4 (en) | 2018-05-23 |
| US10237704B2 (en) | 2019-03-19 |
| US20160366567A1 (en) | 2016-12-15 |
| KR102273533B1 (ko) | 2021-07-06 |
| EP3308560A1 (en) | 2018-04-18 |
| CN107736040A (zh) | 2018-02-23 |
| KR20160147567A (ko) | 2016-12-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2795435T3 (es) | Procedimiento y aparato de implementación de servicio en sistema de comunicación inalámbrica | |
| US12519665B2 (en) | Methods for blockchain offline operations management | |
| JP7317139B2 (ja) | ワイヤレス通信システムにおける制御プレーン上でのセルラー版モノのインターネット(ciot)データ転送のための方法および装置 | |
| EP3643098B1 (en) | Methods and systems for privacy protection of 5g slice identifier | |
| US8594632B1 (en) | Device to-device (D2D) discovery without authenticating through cloud | |
| US9674682B2 (en) | Enabling D2D functionality for public safety applications | |
| JP2023178976A (ja) | スライス固有の認証のための方法と装置 | |
| ES3048217T3 (en) | Load control in a wireless communication system | |
| CN107251591A (zh) | 用于安全的设备到设备发现和通信的系统、方法和设备 | |
| TW201526654A (zh) | 實現視訊通話的方法及系統 | |
| WO2022001849A1 (zh) | 信息处理方法、装置及终端 | |
| CN116235160A (zh) | 涉及通过区块链网络进行消息传送的方法、架构、装置和系统 | |
| EP4503778A1 (en) | Communication related to communication state | |
| WO2019158224A1 (en) | Methods, system, ue, pgw-u and mme for managing traffic differentiation | |
| WO2020168467A1 (en) | Terminal and method for performing a group communication | |
| CN105247802A (zh) | 发现方法和装置 | |
| US20250056642A1 (en) | Connection resume method and apparatus, and communication device and storage medium | |
| WO2023083691A1 (en) | Generating an authentication token | |
| WO2022127808A1 (zh) | 授信中继通信方法、装置、终端及网络侧设备 | |
| US11070677B1 (en) | Techniques for media call multiway relay escalation | |
| WO2022143070A1 (zh) | 一种通信方法和通信系统 | |
| US11824914B1 (en) | System and method for streaming media to a public safety access point without incurring additional user costs | |
| WO2024138618A1 (en) | Method and apparatus for internet key exchange (ike) session management | |
| WO2026065128A1 (en) | Physical layer security enhancement for integrated sensing and communication authentication for mono-static systems | |
| WO2026065120A1 (en) | Physical layer security enhancement for integrated sensing and communication authentication for bi-static systems |