ES2984383T3 - Transporte optimizado de mensajes cortos - Google Patents

Transporte optimizado de mensajes cortos Download PDF

Info

Publication number
ES2984383T3
ES2984383T3 ES16753920T ES16753920T ES2984383T3 ES 2984383 T3 ES2984383 T3 ES 2984383T3 ES 16753920 T ES16753920 T ES 16753920T ES 16753920 T ES16753920 T ES 16753920T ES 2984383 T3 ES2984383 T3 ES 2984383T3
Authority
ES
Spain
Prior art keywords
message
data
sms
network node
mobile
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES16753920T
Other languages
English (en)
Inventor
Adrian Buckley
Jan Hendrik Lucas Bakker
Nicholas James Russell
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Malikie Innovations Ltd
Original Assignee
Malikie Innovations Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Malikie Innovations Ltd filed Critical Malikie Innovations Ltd
Application granted granted Critical
Publication of ES2984383T3 publication Critical patent/ES2984383T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/20—Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/02—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration by periodical registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/005—Discovery of network devices, e.g. terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01D—MEASURING NOT SPECIALLY ADAPTED FOR A SPECIFIC VARIABLE; ARRANGEMENTS FOR MEASURING TWO OR MORE VARIABLES NOT COVERED IN A SINGLE OTHER SUBCLASS; TARIFF METERING APPARATUS; MEASURING OR TESTING NOT OTHERWISE PROVIDED FOR
    • G01D4/00—Tariff metering apparatus
    • G01D4/002—Remote reading of utility meters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/06—Registration at serving network Location Register, VLR or user mobility server
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
    • Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
    • Y04S20/00—Management or operation of end-user stationary applications or the last stages of power distribution; Controlling, monitoring or operating thereof
    • Y04S20/30—Smart metering, e.g. specially adapted for remote reading

Landscapes

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

Abstract

Un método para transferir datos utilizando un transporte de mensajes cortos optimizado incluye recibir en un primer nodo de red un mensaje de solicitud de conexión. El mensaje de solicitud de conexión incluye datos de mensajes cortos. El primer nodo de red recibe de un segundo nodo de red un mensaje de respuesta de datos de mensajes cortos. El mensaje de respuesta de datos de mensajes cortos incluye al menos una de las siguientes opciones: una dirección para un centro de servicio de mensajes cortos, una indicación que indica que no hay ningún mensaje finalizado en móvil pendiente para el UE o una dirección de destino de entidad de mensajes cortos. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Transporte optimizado de mensajes cortos
Reivindicación de prioridad
Campo técnico
Esta descripción se refiere a la transmisión de datos en sistemas de comunicación inalámbrica y, más específicamente, a transporte optimizado de mensajes cortos en un entorno celular de Internet de las cosas.
Antecedentes
En algunos casos, una Internet de las cosas celular (CloT, por sus siglas en inglés) es un escenario en donde un gran número de dispositivos, p. ej., millones o miles de millones de dispositivos, pueden ser servidos por una red inalámbrica. Los dispositivos pueden variar de dispositivos estacionarios en lo profundo de sótanos a dispositivos que tienen velocidad de movilidad limitada. Los dispositivos pueden enviar y/o recibir pequeñas cantidades de datos infrecuentes. Ejemplos de dispositivos CloT pueden incluir medidores inteligentes de servicios públicos como, por ejemplo, medidores de gas, agua o eléctricos que pueden informar de manera autónoma el uso de servicios públicos al proveedor de servicios públicos a través de la red inalámbrica. Otro ejemplo de dispositivos CloT puede incluir sensores de monitoreo ambiental que pueden colocarse aleatoriamente en un área geográfica para monitorear la calidad del aire o del agua. En algunos casos, el servicio de mensajes cortos (SMS, por sus siglas en inglés) puede usarse para que un dispositivo envíe y/o reciba un mensaje corto de hasta 140 bytes/octetos de longitud. La poca e infrecuente cantidad de datos CloT puede incluirse en el mensaje corto y entregarse a la red por SMS.
El documento EP 2615421 A1 describe un método de transferencia de datos de usuario en mensajes de señalización de una unidad de comunicación a un centro de procesamiento de datos. El documento WO 2013/051826 A2 describe un mensaje de conexión combinado o un mensaje de actualización de Área de Seguimiento/Área de Localización (TA/LA, por sus siglas en inglés) combinado enviado desde una Estación Móvil. El documento 3GPP; TR 23.888; septiembre de 2012, describe el uso de un contexto de seguridad NAS preestablecido para transferir PDU SMS como señalización NAS sin establecer seguridad RRC.
Compendio
Se proveen métodos, dispositivos y un medio tangible, no transitorio legible por ordenador como se detalla en las reivindicaciones que siguen.
La realización de la Figura 14 cae dentro del alcance de las reivindicaciones. Todas las demás realizaciones no caen dentro del alcance de las reivindicaciones. Sin embargo, se conservan como ejemplos útiles para comprender mejor la invención.
Descripción de los dibujos
La Figura 1 es un sistema de comunicación inalámbrica a modo de ejemplo que usa transporte optimizado de mensajes cortos para transferir datos en un entorno CloT según una implementación.
La Figura 2 es un diagrama de flujo de datos que ilustra un proceso a modo de ejemplo para usar transporte optimizado de mensajes cortos para transferir datos en un entorno CloT según una implementación.
La Figura 3 es un diagrama de flujo de datos que ilustra un proceso a modo de ejemplo para usar transporte optimizado de mensajes cortos para transferir datos originados en el móvil en un entorno CIoT según una implementación. La Figura 4 es un diagrama de flujo de datos que ilustra un proceso a modo de ejemplo para usar transporte optimizado de mensajes cortos para transferir datos terminados en el móvil en un entorno CIoT según una implementación. La Figura 5 es un diagrama de flujo de datos que ilustra otro proceso a modo de ejemplo para usar transporte optimizado de mensajes cortos para transferir datos terminados en el móvil en un entorno CIoT según una implementación.
La Figura 6 es un diagrama esquemático que ilustra un proceso a modo de ejemplo de un equipo de usuario (EU) que incluye datos originados en el móvil en un Mensaje 1 según una implementación.
La Figura 7 es un diagrama esquemático que ilustra un proceso a modo de ejemplo de un nodo de red 1 que extrae datos originados en el móvil de un Mensaje 1 y que incluye los datos en un Mensaje 7 según una implementación. La Figura 8 es un diagrama esquemático que ilustra un proceso a modo de ejemplo de un nodo de red 1 que extrae datos terminados en el móvil de un Mensaje 3c y que incluye los datos en un Mensaje 6 según una implementación.
La Figura 9 es un diagrama esquemático que ilustra un proceso a modo de ejemplo de un EU que extrae datos terminados en el móvil de un Mensaje 6 según una implementación.
La Figura 10 es un diagrama esquemático que ilustra un proceso a modo de ejemplo de un EU que incluye datos originados en el móvil en un Mensaje 1 sin una dirección del centro de servicio de SMS (SMSC, por sus siglas en inglés) según una implementación.
La Figura 11 es un diagrama esquemático que ilustra un proceso a modo de ejemplo de un nodo de red 1 que extrae datos originados en el móvil de un Mensaje 1 y que incluye los datos en un Mensaje 7, sin que un EU provea una dirección SMSC, según una implementación.
La Figura 12 es un diagrama esquemático que ilustra un proceso a modo de ejemplo de un nodo de red 1 que extrae datos terminados en el móvil de un Mensaje 3c y que incluye los datos en un Mensaje 6 sin una dirección SMSC, según una implementación.
La Figura 13 es un diagrama esquemático que ilustra un proceso 1300 a modo de ejemplo de un EU que extrae datos terminados en el móvil de un Mensaje 6 sin una dirección SMSC según una implementación.
La Figura 14 es un diagrama de flujo que ilustra un método a modo de ejemplo para usar transporte optimizado de mensajes cortos para transferir datos en un entorno CIoT según una implementación.
La Figura 15 es un diagrama de flujo de datos que ilustra un proceso a modo de ejemplo para notificar a un nodo de red 2 un número de mensajes terminados en el móvil pendientes según una implementación.
Las Figuras 16A-16E ilustran una primera descripción a modo de ejemplo de procedimientos de gestión de movilidad del Sistema de Paquetes Evolucionado (EPS, por sus siglas en inglés) (EMM, por sus siglas en inglés) según una implementación.
Las Figuras 17A-17F ilustran una segunda descripción a modo de ejemplo de procedimientos EMM según una implementación.
La Figura 18 ilustra una tercera descripción a modo de ejemplo de procedimientos EMM según una implementación. Las Figuras 19A y 19B ilustran una descripción a modo de ejemplo de un mensaje de aceptación de conexión según una implementación.
La Figura 20 ilustra una descripción a modo de ejemplo de un mensaje de rechazo de conexión según una implementación.
Las Figuras 21A y 21B ilustran una descripción a modo de ejemplo de un mensaje de solicitud de conexión según una implementación.
Las Figuras 22A y 22B ilustran una descripción a modo de ejemplo de la causa EMM según una implementación. La Figura 23 ilustra una descripción a modo de ejemplo del tipo de conexión EPS según una implementación.
La Figura 24 ilustra una descripción a modo de ejemplo de un contenedor de mensajes CIoT según una implementación.
La Figura 25 ilustra una descripción a modo de ejemplo del elemento de información (IE, por sus siglas en inglés) del contenedor de mensajes de datos según una implementación.
La Figura 26 ilustra una descripción a modo de ejemplo del IE de mensajes pendientes según una implementación. Las Figuras 27A-27C ilustran una descripción a modo de ejemplo del servicio MAP_ SEND_AUTHENTICATION_INFO según una implementación.
Las Figuras 28A-28C ilustran una descripción a modo de ejemplo del servicio MAP_UPDATE_LOCATION según una implementación.
Las Figuras 29A-29C ilustran una descripción a modo de ejemplo del servicio MAP_UPDATE_GPRS_LOCATION según una implementación.
Las Figuras 30A-30C ilustran una descripción a modo de ejemplo del servicio MAP-INSERT-SUBSCRIBER-DATA según una implementación.
Las Figuras 31A y 31B ilustran una descripción a modo de ejemplo del servicio MAP-REPORT-SM-DELIVERY-STATUS según una implementación.
La Figura 32 ilustra una descripción a modo de ejemplo del tipo de datos de servicio móvil según una implementación.
La Figura 33 es un esquema que ilustra un nodo de red a modo de ejemplo.
La Figura 34 es un esquema que ilustra un dispositivo de equipo de usuario a modo de ejemplo.
Los números de referencia y las designaciones iguales en los diversos dibujos indican elementos iguales.
Descripción detallada
La presente descripción está dirigida a un transporte de mensajes cortos optimizado para transferir datos en un entorno CIoT. En algunos casos, los dispositivos CIoT pueden tener una fuente de alimentación limitada, p. ej., alimentada por baterías. Ejemplos de dispositivos CIoT con una fuente de alimentación limitada pueden incluir sensores de monitoreo ambiental que se colocan aleatoriamente en un área geográfica para monitorear la calidad del aire o del agua. En algunos casos, para entregar datos de hasta 140 bytes/octetos usando SMS, puede tomar un gran número de mensajes entre el dispositivo CIoT y la red. En algunos casos, si está implicado un SMS basado en el Protocolo de Internet (IP, por sus siglas en inglés), pueden ser necesarios incluso más mensajes y esos mensajes pueden ser significativamente más grandes, p. ej., usando el subsistema multimedia IP (IMS, por sus siglas en inglés) para transportar mensajes cortos. Por ejemplo, cuando no hay transferencia de datos, el dispositivo CIoT puede apagarse o estar en un estado de bajo consumo de batería y no conectarse a la red. Cuando el dispositivo CIoT determina que existe la necesidad de contactar con la red para enviar, recibir, o enviar y recibir datos, el dispositivo CIoT puede encenderse o volver a un estado de consumo de batería normal y conectarse a la red. Para conectarse a la red, el dispositivo puede necesitar llevar a cabo un procedimiento de conexión para registrarse con la red. En algunos casos, se puede llevar a cabo un procedimiento de conexión completo antes de que se pueda entregar un mensaje corto (SM, por sus siglas en inglés). Para mejorar la eficiencia energética del dispositivo CIoT, puede ser deseable un transporte eficiente de mensajes cortos con un número reducido de mensajes. La reducción del número de mensajes puede reducir la cantidad de tiempo que el dispositivo se conecta a la red y, por lo tanto, ahorrar energía. La reducción del número de mensajes también puede liberar recursos de red de modo que la red pueda dar servicio a más dispositivos CIoT.
En algunos casos, se puede incluir un mensaje corto en un mensaje asociado a un procedimiento de conexión para reducir el número de mensajes. Sin embargo, en algunos casos, incluir un mensaje corto en otro mensaje puede aumentar significativamente el tamaño general del mensaje debido a una sobrecarga excesiva del protocolo. Por ejemplo, si está implicado un SMS basado en IP, el tamaño global del mensaje puede aumentar significativamente debido a varios encabezados de protocolo. Por lo tanto, es deseable tener un tamaño de mensaje pequeño cuando se incluye el mensaje corto. El dispositivo puede usar menos potencia para procesar un mensaje de un tamaño pequeño. Los recursos de red también pueden usarse de manera eficiente reduciendo los tamaños de los mensajes.
Para reducir el número de mensajes, el transporte optimizado de mensajes cortos puede incluir datos en un mensaje corto e incluir el mensaje corto en los mensajes asociados al procedimiento de conexión. En este caso, los datos pueden ser entregados durante el procedimiento de conexión sin una configuración de portadora. En algunos casos, como se describe a continuación, el dispositivo CIoT puede desconectarse de la red incluso antes de que se complete el procedimiento de conexión si no hay datos que entregar al dispositivo. Para reducir el tamaño del mensaje, el transporte de mensajes cortos optimizado puede incluir datos en unidades de datos de protocolo (PDU, por sus siglas en inglés) de SMS e incluir las PDU de SMS en los mensajes asociados al procedimiento de conexión sin implicar una sobrecarga excesiva del protocolo.
La Figura 1 es un sistema 100 de comunicación inalámbrica a modo de ejemplo que usa transporte de mensajes cortos optimizado para transferir datos en un entorno CIoT según una implementación. En algunas implementaciones, el procedimiento de conexión puede llevarse a cabo para que un equipo de usuario (EU, también conocido como dispositivo CIoT) se conecte a la red. El procedimiento de conexión puede incluir un procedimiento de autenticación y un procedimiento de actualización de ubicación. El procedimiento de autenticación puede usarse para que el EU y la red lleven a cabo la autenticación mutua entre sí para evitar el uso irresponsable de la red. El procedimiento de actualización de ubicación puede usarse para que el EU actualice la ubicación a la red y para que la red recupere los servicios a los que está abonado el EU, que pueden estar, pero no limitados a, en esa ubicación, como, por ejemplo, servicios de itinerancia.
En el sistema 100 de comunicación a modo de ejemplo, un primer nodo de red puede recibir un mensaje de solicitud de conexión de un EU. El mensaje de solicitud de conexión puede incluir datos de mensajes cortos. Los datos de mensajes cortos pueden ser una PDU de SMS, como, por ejemplo, una de una PDU de SMS-SUBMIT, una PDU de SMS-COMMAND, una PDU de SMS-DELIVER-REPORT o una PDU de SMS-SUBMIT-REPORT.
En el mensaje de solicitud de conexión, el EU puede incluir una indicación de un tipo de servicio de datos que solicitó el EU. El tipo de servicio de datos puede ser uno de, pero no limitado a, origen móvil (MO, por sus siglas en inglés), terminación móvil (MT, por sus siglas en inglés), u origen y terminación móvil. El origen móvil puede referirse al servicio del EU que envía datos a la red. La terminación móvil puede referirse al servicio del EU que recibe datos de la red. El origen y la terminación móvil pueden referirse al servicio del EU que envía y recibe datos a y de la red. En el mensaje de solicitud de conexión, el EU también puede indicar la solicitud del EU de no cambiar a un modo conectado. Ejemplos de MO, MT pueden ser, pero no se limitan a, SMS MO, SMS MT, etc.
En algunas implementaciones, el primer nodo de red puede enviar un segundo mensaje a un segundo nodo de red. El segundo mensaje puede incluir una indicación del tipo de servicio de datos que el EU solicitó. El segundo mensaje puede ser uno de una solicitud de autenticación o una actualización de ubicación. Si el EU solicita al menos un servicio de terminación móvil (p. ej., terminación móvil u origen y terminación móvil), el segundo nodo de red puede proveer la información de si hay mensajes terminados en el móvil pendientes para el EU y/o el número de mensajes pendientes. Si el EU solicita al menos un servicio de origen móvil (p. ej., origen móvil u origen y terminación móvil), el segundo nodo de red puede proveer una dirección de un centro de servicio de mensajes cortos. En algunas implementaciones, los datos de mensaje corto incluidos en el mensaje de solicitud de conexión pueden no necesitar incluir una dirección de un centro de servicio de mensajes cortos.
En algunas implementaciones, el primer nodo de red puede recibir del segundo nodo de red un mensaje de respuesta de datos de mensajes cortos. El mensaje de respuesta de datos de mensajes cortos puede incluir al menos una de una dirección de un centro de servicio de mensajes cortos, una indicación que indica que no hay ningún mensaje terminado en el móvil pendiente para el EU, una indicación que indica un número de mensajes terminados en el móvil pendientes para el EU, o una dirección de destino de entidad de mensaje corto, p. ej., una dirección E.164 de telecomunicación internacional de unión de telecomunicaciones (ITU-T, por sus siglas en inglés) (que también puede conocerse como un número de directorio de abonado internacional de estación móvil (MSISDN, por sus siglas en inglés) o número MSISDN), identificador de recurso uniforme (URI, por sus siglas en inglés) del protocolo de inicio de sesión (SIP, por sus siglas en inglés), etc. El mensaje de respuesta de datos de mensajes cortos puede ser insertar datos de abonado (ISD, por sus siglas en inglés). ISD puede ser un mensaje asociado al procedimiento de actualización de ubicación.
En algunas implementaciones, el primer nodo de red puede transmitir un mensaje de respuesta de conexión al EU. El mensaje de respuesta de conexión puede incluir un indicador que indica si un mensaje terminado en el móvil está pendiente para el EU y/o el número de mensajes pendientes. El mensaje de respuesta de conexión también puede incluir el mensaje terminado en el móvil.
En algunas implementaciones, el primer nodo de red puede recibir el mensaje de respuesta de datos de mensaje corto del segundo nodo de red. Basándose en la dirección del centro de servicio de mensajes cortos incluida en el mensaje de respuesta de datos de mensajes cortos, el primer nodo de red puede determinar el centro de servicio de mensajes cortos. El primer nodo de red puede transmitir los datos de mensajes cortos del EU al centro de servicio de mensajes cortos.
En algunas implementaciones, el primer nodo de red puede transmitir una solicitud de autenticación al EU. La solicitud de autenticación puede indicar si un mensaje terminado en el móvil está pendiente para el EU. Por ejemplo, si el EU solicitó la terminación móvil y no hay ningún mensaje pendiente para el EU, el EU puede desconectarse de la red sin llevar a cabo los procedimientos de autenticación y conexión restantes.
El uso de transporte de mensajes cortos optimizado para transferir datos según los métodos y sistemas descritos en la presente memoria puede proveer una o más ventajas. Por ejemplo, el transporte de mensajes cortos optimizado puede entregar los datos durante el procedimiento de conexión sin una configuración de portadora. El hacer que el EU indique a la red el tipo de servicio de datos puede permitir que la red optimice aún más el comportamiento. Por ejemplo, si el EU solicita la terminación móvil y no hay ningún mensaje pendiente para el EU, la red puede permitir que el EU se desconecte de la red sin finalizar los procedimientos de autenticación y conexión. El reducir el tiempo durante el cual el EU se conecta a la red puede ahorrar significativamente la potencia del EU y hacer que los recursos de red estén disponibles para servir a más EU. Para reducir el tamaño del mensaje, los datos pueden incluirse en las PDU de SMS y enviarse con los mensajes asociados al procedimiento de conexión sin implicar una sobrecarga excesiva del protocolo. El EU ahorra energía de la batería cuando procesa un mensaje con un tamaño de mensaje reducido. En algunos casos, si el EU solicita al menos un servicio de origen móvil, el EU puede no incluir la dirección del centro de servicio de SMS (SMSC) en el mensaje. En su lugar, la red puede proveer la dirección SMSC. La eliminación de la dirección SMSC puede reducir aún más el tamaño del mensaje.
En algunas implementaciones, los datos de servicio suplementarios no estructurados (USSD, por sus siglas en inglés) también pueden usarse para entregar la pequeña cantidad de datos en un entorno CIoT. Un mensaje USSD puede incluir hasta 182 caracteres alfanuméricos. El transporte optimizado de mensajes cortos descrito para SMS en esta solicitud también puede aplicarse a USSD.
En algunas implementaciones, el servicio de origen móvil puede referirse al origen SMS/USSD. El servicio de terminación móvil puede referirse a la terminación SMS/USSD. El servicio de origen y terminación móvil puede referirse al origen y terminación SMS/USSD.
A un nivel alto, el sistema 100 de comunicación inalámbrica a modo de ejemplo incluye una red 104 de comunicación inalámbrica, que incluye o está acoplada de manera comunicable a un nodo 106 de red 1, a un nodo 108 de red 2 y a un nodo 110 de red 3. El sistema 100 de comunicación inalámbrica a modo de ejemplo también incluye un EU 102 que se conecta al nodo 106 de red 1. El EU 102 puede ser un dispositivo CIoT que envía y/o recibe una cantidad de datos pequeña e infrecuente. En algunas implementaciones, un sistema de comunicaciones puede incluir componentes y características adicionales o diferentes y puede configurarse de una manera diferente del sistema 100 a modo de ejemplo que se muestra en la Figura 1. Por ejemplo, un EU se muestra en la Figura 1 en aras de la claridad y brevedad, pero muchos EU pueden incluirse en el sistema 100.
El nodo 106 de red 1 puede ser una entidad de gestión de movilidad (MME, por sus siglas en inglés), un nodo de soporte del servicio general de radio por paquetes de servicio (GPRS, por sus siglas en inglés) (SGSN, por sus siglas en inglés), un nodo de pasarela de señalización de CIoT (C-SGN, por sus siglas en inglés), un centro de conmutación móvil (MSC, por sus siglas en inglés) y una MME conectados entre sí, u otros nodos o entidades de red. El EU puede conectarse al nodo 106 de red 1 a través de una estación base o nodo B evolucionado (eNB, por sus siglas en inglés). El nodo 106 de red 1 puede llevar a cabo funciones de gestión de movilidad para el EU 102 y puede tener el conocimiento de la ubicación del EU 102.
El nodo 108 de red 2 puede ser un Registro de Localización Doméstica (HLR, por sus siglas en inglés), un Servidor de Abonado Doméstico (HSS, por sus siglas en inglés), un Centro de Autenticación (AuC, por sus siglas en inglés), un servidor de Autenticación, Autorización y Contabilidad (AAA, por sus siglas en inglés), un Servidor de función de misión crítica de pulsar para hablar (MCPTT, por sus siglas en inglés), un servidor de datos de usuario MCPTT u otros nodos o entidades de red. Como se describe en detalle a continuación, el nodo 108 de red 2 puede tener el conocimiento de si hay mensajes pendientes para el EU 102 y/o el número de mensajes pendientes. El nodo 108 de red 2 también puede tener el conocimiento de la dirección del nodo 110 de red 3. El nodo 108 de red 2 puede incluir una función de autenticación y base de datos de abonados. En algunas implementaciones, la dirección del nodo 110 de red 3 puede almacenarse en la base de datos de abonados. En un entorno CIoT, el EU puede enviar datos a un nodo de red 3 fijo. Por ejemplo, si el EU es un medidor de servicios públicos inteligente, es probable que el EU pueda enviar informes de uso de servicios públicos al servidor del proveedor de servicios y que el servidor pueda estar asociado a un nodo 110 de red 3 fijo.
El nodo 110 de red 3 puede ser un Centro de Conmutación de Servicios Móviles de Pasarela SMS (SMS-GMSC, por sus siglas en inglés), un Centro de Conmutación Móvil de Interconexión SMS (SMS-IWMSC, por sus siglas en inglés), enrutador SMS, Servicio de Mensajes Cortos - Centro de Servicio (SMS-SC, por sus siglas en inglés o SMSC), u otros nodos o entidades de red. El nodo 110 de red 3 puede ser responsable de almacenar y reenviar mensajes cortos. Por ejemplo, para SMS terminado en el móvil, el nodo 110 de red 3 puede almacenar los mensajes cortos y reenviarlos al EU 102 cuando el EU 102 está disponible para recibir los mensajes cortos. Para SMS originados en el móvil, el nodo 110 de red 3 puede almacenar los mensajes cortos del EU 102 y reenviarlos al servidor de destino o redes externas.
En funcionamiento, el EU 102 puede recibir una indicación de la red 104 inalámbrica que indica si el transporte de mensajes cortos optimizado es soportado por la red 104 inalámbrica. Si se soporta, la indicación puede indicar además qué transporte optimizado de mensajes cortos soporta la red (p. ej., SMS a través de conexión, USSD a través de conexión, etc.). En algunas implementaciones, la indicación puede ser implícita mediante el descubrimiento de una tecnología de acceso por radio (RAT, por sus siglas en inglés) que se sabe que soporta el transporte optimizado de mensajes cortos. En algunas otras implementaciones, la indicación es difundida al EU 102 por la red 104 inalámbrica. Alternativamente, el EU puede no recibir la indicación e intentar el procedimiento del transporte de mensajes cortos optimizado de todos modos, en cuyo caso el EU puede almacenar si el procedimiento tuvo éxito o no. Este almacenamiento puede usarse más tarde cuando hay datos adicionales para enviar a la red.
Cuando el EU 102 determina que existe la necesidad de enviar, recibir o enviar y recibir datos, el EU 102 puede encenderse o volver al estado de consumo de batería normal y conectarse a la red 104 inalámbrica. Para conectarse a la red 104 inalámbrica, el EU 102 puede necesitar llevar a cabo un procedimiento de conexión para registrarse con la red 104 inalámbrica.
El EU 102 puede enviar un mensaje de solicitud de conexión al nodo 106 de red 1. En una realización, en el mensaje de solicitud de conexión, el EU 102 puede incluir una indicación del tipo de servicio de datos que solicita el EU 102. El tipo de servicio de datos puede ser uno de entre, pero sin limitarse a, origen móvil, terminación móvil, u origen y terminación móvil. Por ejemplo, si el EU 102 es un medidor de servicios públicos inteligente y desea enviar el informe de uso de servicios públicos al proveedor de servicios públicos, el EU 102 puede indicar el origen móvil en el mensaje de solicitud de conexión. Si el EU 102 se conecta a la red 104 para comprobar actualizaciones o notificaciones del sistema, el EU 102 puede indicar la terminación móvil en el mensaje de solicitud de conexión. Si el EU 102 desea enviar y recibir datos, el EU 102 puede indicar origen y terminación móvil. El EU 102 puede tener diferentes razones cada vez que se activa y se conecta a la red 104. Dependiendo de la razón, el EU 102 puede indicar a veces origen móvil, a veces terminación móvil, y a veces origen y terminación móvil. En algunas implementaciones, la inclusión de la indicación del tipo de servicio de datos en el mensaje de solicitud de conexión también puede notificar a la red 104 que el EU 102 desea conectarse a la red sin llevar a cabo una configuración de portadora.
Si el EU 102 tiene datos para enviar (p. ej., origen móvil u origen y terminación móvil), el EU 102 puede incluir los datos en una PDU SMS. El EU 102 puede incluir la PDU SMS en el mensaje de solicitud de conexión y enviar el mensaje de solicitud de conexión al nodo 106 de red 1. En algunas implementaciones, el EU 102 puede no incluir la dirección del nodo 110 de red 3 (p. ej., SMSC) en la PDU SMS. Como se describe con más detalle a continuación, el nodo 106 de red 1 puede obtener la dirección del nodo 110 de red 3 (p. ej., SMSC) del nodo 108 de red 2. En el mensaje de solicitud de conexión, el EU 102 también puede indicar que el EU 102 solicita no pasar a un modo conectado después del procedimiento de conexión.
En algunas implementaciones, si el EU 102 solicita la terminación móvil, el EU 102 puede enviar una indicación para la conexión de SMS solamente y no incluir una PDU de SMS en el mensaje de solicitud de conexión.
El nodo 106 de red 1 puede enviar un mensaje al nodo 108 de red 2 que incluye la indicación del tipo de servicio de datos que el EU 102 solicitó. El mensaje puede ser una solicitud de autenticación asociada al procedimiento de autenticación o un mensaje de actualización de ubicación asociado al procedimiento de actualización de ubicación. Dependiendo del tipo de servicio de datos que el EU solicitó, el nodo 108 de red 2 puede proveer información relacionada. Por ejemplo, si el EU solicita al menos un servicio de origen móvil (p. ej., origen móvil u origen y terminación móvil), el nodo 108 de red 2 puede proveer la dirección del nodo 110 de red 3 (p. ej., SMSC). Si el EU 102 solicita al menos un servicio de terminación móvil (p. ej., terminación móvil u origen y terminación móvil), el nodo 108 de red 2 puede proveer la información de si hay mensajes pendientes para el EU 102 y/o el número de mensajes pendientes. Si hay mensajes pendientes para el EU 102 y el EU 102 solicitó al menos el servicio de terminación móvil, el nodo 108 de red 2 puede notificar al nodo 110 de red 3 que el EU 102 está disponible para recibir los mensajes pendientes y, a su vez, el nodo 110 de red 3 puede reenviar los mensajes pendientes al nodo 106 de red 1.
El nodo 108 de red 2 puede enviar un mensaje de respuesta de datos de mensaje corto al nodo 106 de red 1 y proveer información relacionada con el servicio de datos que el EU 102 solicitó. El mensaje de respuesta de datos de mensaje corto puede ser un mensaje de insertar datos de abonado (ISD) asociado al procedimiento de actualización de ubicación. Si el EU 102 solicitó al menos un servicio de terminación móvil, el mensaje de respuesta de datos de mensaje corto puede indicar si hay un mensaje pendiente para el EU 102 y/o el número de mensajes pendientes. Si el EU 102 solicita al menos un servicio de origen móvil, el mensaje de respuesta de datos de mensaje corto puede incluir la dirección del nodo 110 de red 3 de modo que el nodo 106 de red 1 puede reenviar los datos originados en el móvil al nodo 110 de red 3. En algunas implementaciones, el mensaje de respuesta de datos de mensaje corto puede ser un mensaje de respuesta de vectores de autenticación asociado al procedimiento de autenticación que puede indicar si hay mensajes pendientes para el EU y/o el número de mensajes pendientes.
En algunas implementaciones, el nodo 106 de red 1 puede enviar una solicitud de autenticación al EU 102. La solicitud de autenticación puede indicar si hay un mensaje pendiente para el EU 102. Si no hay ningún mensaje pendiente para el EU 102 y el EU 102 solicitó la terminación móvil, el EU 102 puede desconectarse de la red sin llevar a cabo el procedimiento de autenticación restante y el procedimiento de conexión para ahorrar energía.
En algunas implementaciones, después de la autenticación exitosa, el nodo 106 de red 1 puede transmitir un mensaje de respuesta de conexión al EU 102. El mensaje de respuesta de conexión puede indicar si hay mensajes terminados en el móvil pendientes para el EU 102. El mensaje de respuesta de conexión también puede incluir el mensaje terminado en el móvil que incluye los datos que se entregarán al EU 102. En algunas implementaciones, si los datos pueden encajar en el único mensaje de respuesta de conexión, el mensaje de respuesta de conexión puede ser un rechazo de conexión y el EU 102 puede desconectarse de la red después de recibir los datos del rechazo de conexión.
Las Figuras 2-9 y las descripciones asociadas proveen detalles adicionales para implementaciones a modo de ejemplo. Una persona con experiencia en la técnica apreciará que las implementaciones pueden mezclarse y coincidir.
Con referencia a una descripción general de los elementos, un EU puede denominarse dispositivo electrónico móvil, dispositivo de usuario, estación móvil, estación de abonado, dispositivo electrónico portátil, dispositivo de comunicaciones móviles, módem inalámbrico, terminal inalámbrico, equipo móvil, agente de usuario del protocolo de inicio de sesión (SIP), decodificador, equipo de prueba, módem integrado o dispositivo CIoT. Ejemplos de un EU pueden incluir un teléfono celular, un asistente personal de datos (PDA, por sus siglas en inglés), un teléfono inteligente, un ordenador portátil, un ordenador personal (PC, por sus siglas en inglés) de tableta, un localizador, un dispositivo de juegos portátil, un dispositivo electrónico ponible u otro dispositivo de comunicaciones móviles que tenga componentes para comunicar datos a través de una red de comunicación inalámbrica. La red de comunicación inalámbrica puede incluir un enlace inalámbrico en al menos uno de un espectro con licencia y un espectro sin licencia.
Otros ejemplos de un EU incluyen dispositivos electrónicos móviles y fijos. Un EU puede incluir un dispositivo de equipo móvil (ME, por sus siglas en inglés) y un módulo de memoria extraíble, como, por ejemplo, una tarjeta de circuito integrado universal (UICC, por sus siglas en inglés) que incluye una aplicación de módulo de identidad de abonado (SIM, por sus siglas en inglés), una aplicación de módulo de identidad de abonado universal (USIM, por sus siglas en inglés), o una aplicación de módulo de identidad de usuario extraíble (R-UIM, por sus siglas en inglés). El término "EU" también puede referirse a cualquier componente de hardware o software que pueda terminar una sesión de comunicación para un usuario. Además, los términos "equipo de usuario", "EU", "dispositivo de equipo de usuario", "agente de usuario", "UA", "dispositivo de usuario" y "dispositivo móvil" se pueden usar como sinónimos en la presente memoria.
La red 104 de comunicación inalámbrica puede incluir una o múltiples redes de acceso por radio (RAN, por sus siglas en inglés), otras redes de acceso como, por ejemplo, Ethernet fija o WLAN IEEE 802.11, redes centrales (CN, por sus siglas en inglés) y redes externas. Las RAN pueden comprender una o más tecnologías de acceso por radio. En algunas implementaciones, las tecnologías de acceso por radio pueden ser el Sistema Global para Comunicaciones Móviles (GSM, por sus siglas en inglés), el Estándar Provisional 95 (IS-95), el Sistema Universal de Telecomunicaciones Móviles (UMTS, por sus siglas en inglés), CDMA2000 (Acceso Múltiple por División de Código), el Sistema Universal Evolucionado de Telecomunicaciones Móviles (UMTS), la Evolución a Largo Plazo (LTE, por sus siglas en inglés) o LTE Avanzada. En algunos casos, las redes centrales pueden ser núcleos de paquetes evolucionados (EPC, por sus siglas en inglés). Las redes centrales pueden incluir entidad de gestión de movilidad (MME), un nodo de soporte del servicio general de radio por paquetes de servicio (GPRS) (SGSN), nodo de pasarela de señalización CIoT (C-SGN), centro de conmutación móvil (MSC) y MME conectados entre sí, registro de ubicación doméstica (HLR), servidor de abonado doméstico (HSS), centro de autenticación (AuC), PS-UDF, servidor de autenticación, autorización y contabilidad (AAA), centro de conmutación de servicios móviles de pasarela SMS (SMS-GMSC), centro de conmutación móvil de interconexión (IWMSC), enrutador de SMS, SMSC u otros nodos o entidades de red.
La red 104 inalámbrica puede ser una red CIoT dedicada a servir a dispositivos CIoT. En algunas implementaciones, la red CIoT puede tener su propio espectro de frecuencia y nodos de red. En algunas implementaciones, la red CIoT puede ser parte de otra red (p. ej., una red GSM, UMTS, CDMA2000, UMTS o LTE) y compartir el espectro de frecuencia y los nodos de red con la otra red.
Aunque los elementos de la Figura 1 se muestran como unos que incluyen diversas partes de componentes, porciones o módulos que implementan las diversas características y funcionalidad, sin embargo, estos elementos pueden incluir en su lugar varios submódulos, servicios de terceros, componentes, bibliotecas y similares, según corresponda. Además, las características y funcionalidad de diversos componentes pueden combinarse en menos componentes según corresponda.
La Figura 2 es un diagrama de flujo de datos que ilustra un proceso 200 a modo de ejemplo para usar transporte optimizado de mensajes cortos para transferir datos en un entorno CIoT según una implementación. El diagrama de flujo de datos incluye el EU 102, el nodo 106 de red 1, el nodo 108 de red 2 y el nodo 110 de red 3. El diagrama de flujo de datos también incluye los Mensajes 1, 2, 3a-3e y 4-7 correspondientes a las operaciones 1, 2, 3a-3e y 4-7. Una persona con experiencia en la técnica apreciará que las operaciones 1, 2, 3a-3e y 4-7 pueden ser eventos concurrentes, simultáneos o superpuestos. La siguiente tabla enumera los posibles nodos de red para el nodo 106 de red 1, el nodo 108 de red 2 y el nodo 110 de red 3. La tabla también enumera los posibles mensajes para los Mensajes 1, 2, 3a-3e y 4-7 correspondientes a las operaciones 1,2, 3a-3e y 4-7.
Tabla 1: descripción de nodos y mensajes de red
Los datos enviados del EU 102 a la red pueden referirse a los Datos 1 (es decir, datos originados en el móvil). Los datos enviados de la red al EU 102 pueden referirse a los Datos 2 (es decir, datos terminados en el móvil). En algunas implementaciones, los Datos 1 pueden ser una de las siguientes PDU de SMS: una PDU de SMS-PRESENTAR, una PDU de COMANDO de SMS, una PDU de INFORME DE ENTREGA de SMS o una PDU de INFORME DE PRESENTACIÓN de SMS. Los datos 2 pueden ser una de las siguientes PDU de SMS: una PDU de entrega de SMS, una PDU de INFORME DE ESTADO DE SMS, una PDU de INFORME DE ENTREGA DE SMS o una PDU de INFORME DE PRESENTACIÓN DE SMS.
Como se muestra en la Figura 2, antes de la operación 1, el EU 102 puede estar en modo inactivo o en un estado de bajo consumo de batería y el EU 102 no está conectado o unido a la red. El EU 102 puede determinar que necesita contactar con la red para enviar, recibir o enviar y recibir datos. El EU 102 puede recibir una indicación de que la red soporta el envío de datos de una manera optimizada (p. ej., transporte de mensajes cortos optimizado para SMS o USSD) en su primer mensaje de señalización de Estrato de No Acceso (NAS, por sus siglas en inglés) enviado a la red. En algunas implementaciones, la indicación puede ser implícita por el tipo de RAT de la red. Por ejemplo, el transporte optimizado de mensajes cortos puede soportarse en una rAt particular. El EU 102 también puede recibir la indicación a través de un mensaje de difusión de la red que incluye un punto(s) de código que identifica el transporte de mensajes cortos optimizado soportado. El transporte optimizado de mensajes cortos puede ser uno o más de SMS en conexión, USSD en conexión o SMS/USSD en conexión.
En la operación 1, el EU 102 puede enviar un Mensaje 1 al nodo 106 de red 1 (p. ej., C-SGN, MME, etc.). El Mensaje 1 puede ser un mensaje de solicitud de conexión. El Mensaje 1 puede incluir un identificador que identifica el EU 102. El identificador puede ser un tipo de identidad privada como, por ejemplo, una identidad interna de abonado móvil (IMSI, por sus siglas en inglés) o una identidad temporal globalmente única (GUTI, por sus siglas en inglés). Si el EU 102 desea enviar datos, los datos originados en el móvil pueden incluirse en una PDU SMS. En algunas implementaciones, el Mensaje 1 también puede incluir una indicación del tipo de servicio de datos solicitado por el EU 102. El servicio de datos puede ser uno de, pero no limitado a, origen móvil, terminación móvil, u origen y terminación móvil. En algunas implementaciones, la inclusión de la indicación del tipo de servicio de datos en el Mensaje 1 puede notificar a la red que el EU 102 desea conectarse a la red sin llevar a cabo una configuración de portadora.
En algunas implementaciones, el Mensaje 1 puede no incluir los siguientes elementos de información de mensaje corto: dirección del centro de servicio de mensajes cortos (dirección SMSC) y dirección de destino de la entidad de mensaje corto (SME TP-DA, por sus siglas en inglés). En la SME TP-DA, el Tipo de Número (TON, por sus siglas en inglés) y la Identificación del Plan de Numeración (NPI, por sus siglas en inglés) pueden establecerse ambos como "desconocidos" con una longitud de dirección de cero dígitos. Una persona con experiencia en la técnica apreciará que cualquier configuración de punto de código en TON y NPI puede usarse siempre que la red conozca que estas configuraciones implican que no se incluye SME TP-DA.
En algunas implementaciones, el Mensaje 1 puede incluir una indicación de que el EU 102 no desea pasar al modo CONECTADO después del procedimiento de conexión. En algunas implementaciones, la indicación puede derivarse implícitamente del servicio de datos que el EU 102 solicitó.
En algunas implementaciones, la indicación del servicio de datos solicitado puede ser un nuevo punto de código en un elemento de información existente, un nuevo elemento de información, o puede ser un conjunto específico (1 a muchos) de caracteres en el elemento de información de nombre de punto de acceso (APN, por sus siglas en inglés). En algunas implementaciones, el punto de código para la indicación del servicio de datos que el EU solicitó es tal que el nodo 106 de red 1 no establece una portadora IP.
Cuando el nodo 106 de red 1 recibe el Mensaje 1, si el EU 102 necesita ser autenticado, entonces el nodo 106 de red 1 lleva a cabo procedimientos de autenticación como se muestra en las operaciones 2a, 3a, 4 y 5.
En la operación 2, el nodo 106 de red 1 puede enviar un Mensaje 2 al nodo 108 de red 2 (p. ej., HSS, etc.). El mensaje 2 puede ser una solicitud de autenticación. El mensaje 2 puede incluir el identificador de EU (p. ej., la identidad privada como, por ejemplo, IMSI, GUTI) que se recibió en el Mensaje 1, así como la dirección del nodo 106 de red 1 (p. ej., título global, número E.164, localizador uniforme de recursos, etc.). En algunas implementaciones, el Mensaje 2 también puede incluir el tipo de servicio de datos que el EU solicitó que puede haber sido recibido en el Mensaje 1.
En algunas implementaciones, el nodo 108 de red 2 incluye una función de autenticación, p. ej., HSS con función de autenticación. Cuando el nodo 108 de red 2 recibe el Mensaje 2 y determina que el EU 102 no está autorizado para llevar a cabo el servicio de datos solicitado, el nodo 108 de red 2 puede responder con un mensaje de rechazo al nodo 106 de red 1.
Cuando el nodo 108 de red 2 recibe el Mensaje 2 y determina que el EU 102 está autorizado para llevar a cabo el servicio de datos solicitado, el nodo 108 de red 2 puede llevar a cabo uno o ambos de los siguientes: (1) el nodo 108 de red 2 puede generar o crear vectores de autenticación a enviarse al EU 102; (2) si el nodo 108 de red 2 tiene una indicación de que hay mensajes pendientes para enviarse al EU 102 y el EU 102 ha indicado que está conectado a la red para al menos un servicio de terminación móvil, el nodo 108 de red 2 puede enviar una notificación al nodo 110 de red 3 (p. ej., SMSC, etc.) para indicar que el EU 102 está disponible para recibir los mensajes pendientes. Por ejemplo, como se describe a continuación, el nodo 108 de red 2 puede enviar un Mensaje 3b al nodo 110 de red 3.
En la operación 3a, el nodo 108 de red 2 puede enviar un Mensaje 3a al nodo 106 de red 1. El Mensaje 3a puede ser una respuesta de datos de mensaje corto. El Mensaje 3a puede incluir los vectores de autenticación generados por el nodo 108 de red 2. El Mensaje 3a también puede incluir una indicación de si hay mensajes pendientes que se enviarán al EU 102 y/o el número de mensajes pendientes que puede variar de 0 a muchos.
En algunas implementaciones, si el EU 102 solicitó terminación móvil y no hay mensajes pendientes para el EU 102, el Mensaje 3a puede incluir una indicación de que no hay mensajes pendientes o puede ser un mensaje de rechazo con un valor de causa opcional "no hay mensajes pendientes".
En la operación 3b, el nodo 108 de red 2 puede enviar un Mensaje 3b al nodo 110 de red 3. En algunas implementaciones, el Mensaje 3b se envía debido a la recepción del Mensaje 2 y el servicio de datos solicitado indicado en el Mensaje 2 fue al menos un servicio de terminación móvil. En algunas implementaciones, el Mensaje 3b se envía debido a la recepción del Mensaje 3d, como se describe en detalle a continuación, y el servicio de datos solicitado indicado en el Mensaje 3d fue al menos un servicio de terminación móvil. En algunas implementaciones, el Mensaje 3b se envía si el EU solicitó al menos el servicio de terminación móvil y el nodo 108 de red 2 sabe que hay mensajes pendientes para el EU. En algunas implementaciones, el propósito del Mensaje 3b es notificar al nodo 110 de red 3 que el EU 102 está disponible para recibir los mensajes pendientes de modo que el nodo 110 de red 3 puede enviar los mensajes pendientes al nodo 106 de red 1 y el nodo 106 de red 1 puede enviar además los mensajes pendientes al EU 102.
El mensaje 3b puede incluir un identificador de EU para el EU 102. El identificador de EU en el Mensaje 3b puede ser un identificador diferente del de los Mensajes 1 y 2. En algunas implementaciones, el identificador de EU en el Mensaje 3b puede ser una identidad de EU pública como, por ejemplo, el Número de Directorio de Abonado Internacional de Estación Móvil (MSISDN) o un identificador de recursos uniforme (URI). El Mensaje 3b también puede incluir la dirección del nodo 106 de red 1 (p. ej., título global, número E.164, URL, etc.). En algunas implementaciones, al transportar la dirección del nodo 106 de red 1 (p. ej., C-SGN o MME que es responsable de las funciones de movilidad del EU y tiene conocimiento de la ubicación del EU), el nodo 110 de red 3 puede saber cómo enviar los mensajes pendientes al EU 102. Por ejemplo, el nodo 110 de red 3 puede enviar los mensajes pendientes al nodo 106 de red 1 y el nodo 106 de red 1, que conoce la ubicación del EU, puede reenviar además los mensajes pendientes al EU 102.
En la operación 3c, el nodo 110 de red 3 (p. ej., SMSC) puede enviar uno o más Mensajes 3c al nodo 106 de red 1. Tras recibir el Mensaje 3b que indica que el EU 102 está disponible para recibir mensajes pendientes, el nodo 110 de red 3 puede crear el Mensaje 3c. Dependiendo de la cantidad de datos a enviar, el nodo 110 de red 3 puede enviar un Mensaje 3c o múltiples Mensajes 3c. Cada Mensaje 3c puede incluir un identificador de EU (p. ej., la identidad pública como, por ejemplo, MSISDn o URI) y los datos que van a entregarse al EU. Los datos para el EU pueden incluirse en PDU de SMS. Después de recibir el Mensaje 3c, el nodo 106 de red 1 puede almacenar los datos para el EU 102.
En la operación 3d, el nodo 106 de red 1 puede enviar un Mensaje 3d al nodo 108 de red 2. El Mensaje 3d puede ser una actualización de ubicación. Si el Mensaje 2 no incluye el tipo de servicio de datos que el EU solicitó o el Mensaje 3a no incluye la indicación de si hay mensajes pendientes para el EU, el nodo 106 de red 1 puede enviar el Mensaje 3d. El Mensaje 3d puede incluir uno o más del identificador de EU (p. ej., la identidad privada IMSI o GUTI) que se recibió en el Mensaje 1, la dirección del nodo 106 de red 1 (p. ej., título global, número E.164, URL, etc.), o el tipo de servicio de datos que solicitó el EU. Una persona con experiencia en la técnica apreciará que la operación 3d normalmente tendrá lugar después de la operación 5.
Cuando el nodo 108 de red 2 recibe el Mensaje 3d, si el nodo 108 de red 2 tiene una indicación de que hay mensajes pendientes para ser enviados al EU y el EU ha indicado que está conectado a la red para al menos un servicio de terminación móvil, el nodo 108 de red 2 puede enviar una notificación al nodo 110 de red 3 que indica que el EU está disponible para recibir los datos pendientes. Por ejemplo, el nodo 108 de red 2 puede enviar el Mensaje 3b al nodo 110 de red 3.
En la operación 3e, el nodo 108 de red 2 puede enviar un Mensaje 3e al nodo 106 de red 1. El Mensaje 3e puede ser una respuesta de datos de mensaje corto. El Mensaje 3e puede incluir una o más de una indicación de que hay mensajes pendientes o no hay mensajes pendientes a entregarse al EU, el número de mensajes pendientes que puede variar de 0 a muchos, la dirección de SMSC que va a usarse para enviar los datos originados en el móvil a, o la dirección de destino de entidad de mensaje corto (SME, por sus siglas en inglés) que va a usarse dentro del mensaje SMS.
En algunas implementaciones, si el EU 102 solicitó terminación móvil y no hay mensajes pendientes para el EU 102, el Mensaje 3e puede incluir una indicación de que no hay mensajes pendientes o puede ser un mensaje de rechazo con un valor de causa opcional "no hay mensajes pendientes".
En la operación 4, el nodo 106 de red 1 puede enviar un Mensaje 4 al EU 102. En algunas implementaciones, el nodo 106 de red 1 envía el Mensaje 4 al recibir el Mensaje 3a. El Mensaje 4 puede no tener que esperar a que se envíe el Mensaje 3d y a que se reciba el Mensaje 3e. El Mensaje 4 puede incluir los vectores de autenticación. El Mensaje 4 también puede incluir la indicación de que hay mensajes pendientes o no hay mensajes pendientes a entregarse al EU o el número de mensajes pendientes que puede variar de 0 a muchos.
En algunas implementaciones, si el EU 102 solicitó terminación móvil y no hay mensajes pendientes para el EU 102, el Mensaje 4 puede incluir una indicación de que no hay mensajes pendientes o puede ser un mensaje de rechazo, por ejemplo, un rechazo de conexión con un valor de causa opcional "no hay mensajes pendientes".
En algunas implementaciones, si el Mensaje 3a o el Mensaje 3e es un mensaje de rechazo con un valor de causa opcional "no hay mensajes pendientes", el Mensaje 4 también puede ser un mensaje de rechazo con un valor de causa opcional "no hay mensajes pendientes".
T ras recibir el Mensaje 4, el EU 102 puede llevar a cabo la autenticación basándose en los vectores de autenticación recibidos en el Mensaje 4. Tras validar el EU 102 que el desafío de autenticación basado en los vectores de autenticación es uno legítimo, si el Mensaje 4 incluye una indicación de que hay mensajes pendientes y el EU solicitó al menos el servicio de terminación móvil, el EU 102 puede almacenar la indicación de los mensajes pendientes y/o el número de mensajes pendientes, que puede variar de 0 a muchos. En algunas implementaciones, si el Mensaje 4 incluye una indicación de que no hay ningún mensaje pendiente y el EU solicitó la terminación móvil, el EU 102 puede no llevar a cabo el resto del proceso de autenticación y conexión y volver al estado INACTIVO.
En la operación 5, el EU 102 envía un Mensaje 5 al nodo 106 de red 1. Por ejemplo, el Mensaje 5 puede incluir la respuesta de autenticación asociada a los vectores de autenticación recibidos en el Mensaje 4. Basándose en la respuesta de autenticación recibida en el Mensaje 5, el nodo 106 de red 1 puede determinar si el proceso de autenticación es exitoso o no. Por ejemplo, el proceso de autenticación es exitoso si la respuesta de autenticación recibida en el Mensaje 5 coincide con la respuesta de autenticación almacenada en el nodo 106 de red 1 que se recibió del Mensaje 3a.
En la operación 6, el nodo 106 de red 1 puede enviar un Mensaje 6 al EU 102. El Mensaje 6 puede ser un mensaje de respuesta de conexión. Tras una autenticación exitosa, si el EU solicitó al menos un servicio de terminación móvil (p. ej., terminación móvil, origen y terminación móvil), el nodo 106 de red 1 puede determinar si hay mensajes pendientes a entregarse al EU. Por ejemplo, si el nodo 106 de red 1 no ha recibido una indicación en el Mensaje 3a o en el Mensaje 3e que indica mensajes pendientes o el nodo 106 de red 1 no ha recibido ningún Mensaje 3c que incluye mensajes pendientes, el nodo 106 de red 1 puede determinar que no hay ningún mensaje pendiente para el EU. Si el nodo 106 de red 1 tiene mensajes pendientes almacenados de uno o más Mensajes 3c recibidos, el nodo 106 de red 1 puede determinar que hay mensajes pendientes para el EU 102.
Si el EU 102 solicitó al menos un servicio de terminación móvil y no hay ningún mensaje pendiente para el EU, y, si el EU ha enviado datos originados en el móvil en el Mensaje 1 y los datos originados en el móvil han sido recibidos por la red, entonces el Mensaje 6 puede ser un rechazo de conexión con indicaciones que indiquen "recepción exitosa de datos" y "no hay mensajes terminados pendientes". Después de recibir el rechazo de conexión, el EU 102 puede desconectarse de la red.
Si el EU 102 solicitó al menos un servicio de terminación móvil y no hay ningún mensaje pendiente para el EU, y, si el nodo 106 de red 1 ha recibido una indicación en el Mensaje 1 que indica al menos un servicio de origen móvil pero no se recibieron datos originados en el móvil, entonces el Mensaje 6 puede ser un rechazo de conexión con un valor de causa que indica un error. Después de recibir el rechazo de conexión, el EU 102 puede desconectarse o separarse de la red e intentar el procedimiento en la Figura 2 de nuevo.
Si el EU solicitó el servicio de terminación móvil y no hay ningún mensaje pendiente para el EU, el Mensaje 6 puede ser un rechazo de conexión con la causa "no hay mensajes terminados pendientes". Después de recibir el rechazo de conexión, el EU 102 puede desconectarse de la red.
Si el EU solicitó al menos el servicio de terminación móvil y hay mensajes pendientes almacenados en el nodo 106 de red 1, y, si los datos terminados en el móvil que se recibieron en el uno o más Mensajes 3c encajan en un único Mensaje 6, y, si el EU ha enviado los datos originados en el móvil en el Mensaje 1 y los datos originados en el móvil se recibieron por la red, entonces el Mensaje 6 puede incluir indicaciones que indican "recepción exitosa de datos" e incluyen los datos terminados en el móvil. En algunas implementaciones, el Mensaje 6 puede ser un rechazo de conexión y el EU 102 puede desconectarse de la red después de recibir los datos terminados en el móvil del rechazo de conexión.
Si el EU solicitó al menos un servicio de terminación móvil y hay mensajes pendientes almacenados en el nodo 106 de red 1, y, si los datos terminados en el móvil que se recibieron en el uno o más Mensajes 3c no encajan en un único Mensaje 6, y, si se recibió una indicación en el Mensaje 1 de que el EU desea pasar al modo CONECTADO o no se recibió tal indicación, entonces el nodo 106 de red 1 puede enviar cualquiera de los siguientes al EU 102: (i) Mensaje 6 (p. ej., una aceptación de conexión); (ii) Mensaje 6 (p. ej., una aceptación de conexión) con una indicación que indica datos pendientes a enviarse; (iii) Mensaje 6 (p. ej., una aceptación de conexión) con una indicación del número de mensajes pendientes a enviarse de vuelta; (iv) Mensaje 6 (p. ej., una aceptación de conexión) que incluye datos terminados en el móvil de un Mensaje 3c, p. ej., el primer Mensaje 3c recibido, y una indicación de que se deben enviar datos adicionales o el número de mensajes pendientes que se deben enviar de vuelta. En algunas implementaciones, si el EU 102 recibe una aceptación de conexión, el EU 102 puede volver a la gestión heredada para al menos servicios de terminación móvil. El EU 102 puede permanecer unido a la red hasta que el EU 102 reciba el número de mensajes cortos identificados en el Mensaje 4 o el Mensaje 6. En algunas implementaciones, el EU 102 puede permanecer unido a la red durante un período que depende de la implementación o que se provee a la red.
Si el EU solicitó al menos un servicio de terminación móvil y hay mensajes pendientes almacenados en el nodo 106 de red 1, y, si los datos terminados en el móvil que se recibieron en el uno o más Mensajes 3c no encajan en un único Mensaje 6, y, si se recibió una indicación en el Mensaje 1 de que el EU 102 no desea pasar al modo CONECTADO y permanecer en INACTIVO, entonces el nodo 106 de red 1 puede enviar cualquiera de los siguientes al EU 102: (i) Mensaje 6 (p. ej., un rechazo de conexión); (ii) Mensaje 6 (p. ej., un rechazo de conexión) con una indicación de que hay datos pendientes a enviarse; (iii) Mensaje 6 (p. ej., un rechazo de conexión) con una indicación con número de mensajes pendientes a enviarse de vuelta; (iv) Mensaje 6 (p. ej.,, un rechazo de conexión) que incluye datos de un Mensaje 3c, p. ej., el primer Mensaje 3c recibido, y una indicación de que se deben enviar datos adicionales o el número de mensajes pendientes que se deben enviar de vuelta. En algunas implementaciones, si el EU 102 recibe un rechazo de conexión con una indicación de mensajes pendientes o un número de mensajes pendientes que van a enviarse, el EU 102 repetirá entonces el procedimiento en la Figura 2 desde la operación 1. Cuando repite el procedimiento, el EU 102 puede solicitar al menos un servicio de terminación móvil y, opcionalmente, no enviar la indicación de no pasar a un modo CONECTADO.
Si el EU 102 se mueve al modo CONECTADO, el nodo 106 de red 1 puede volver al comportamiento de entrega de SMS heredado para entregar los mensajes pendientes. Para mensajes cortos pendientes, estos pueden ser procedimientos SMS heredados para entregar los mensajes cortos pendientes. En algunas implementaciones, el nodo 106 de red 1 puede no enviar ningún mensaje adicional.
Si en el Mensaje 1 el EU solicitó el origen móvil, y, si los datos originados en el móvil se enviaron en el Mensaje 1 y se recibieron por la red, entonces el Mensaje 6 puede incluir una indicación que indique "recepción exitosa de datos".
Si en el Mensaje 1 el EU solicitó origen móvil pero no se incluyeron datos originados en EL móvil en el Mensaje 1, entonces el Mensaje 6 puede enviarse con un valor de causa que indica un error "datos no recibidos".
En algunas implementaciones, para cada entrega de mensaje exitosa para datos terminados en EL móvil, el nodo 106 de red 1 puede crear un registro de detalle de llamada (CDR, por sus siglas en inglés) que incluye una indicación que puede incluir cualquiera o ninguno de los siguientes: tipo de datos recibidos en Conectar (p. ej., SMS, USSD), tipo de datos dentro de ese tipo (p. ej., SMS-DELIVER) o tamaño de los datos.
En la operación 7, tras una autenticación exitosa después de la operación 5, el nodo 106 de red 1 puede enviar un Mensaje 7 al nodo 110 de red 3. El Mensaje 7 puede incluir los datos originados en el móvil recibidos del Mensaje 1. En algunas implementaciones, el Mensaje 7 solo puede enviarse tras la recepción del Mensaje 3e.
En algunas implementaciones, si los datos originados en el móvil en el Mensaje 1 son un mensaje SMS, el nodo 106 de red 1 puede extraer la PDU SMS (p. ej., SMS-SUBMIT) e insertarla en un mensaje MAP_MO_Fo RWARD SHORT. Si la dirección SMSC no se recibió del EU 102 en el Mensaje 1 y se recibió una dirección SMSC en el Mensaje 3e, el nodo 106 de red 1 puede usar la dirección SMSC que se recibió en el Mensaje 3e en el Mensaje 7. Si se recibió una dirección de destino de SME en el Mensaje 3e, el nodo 106 de red 1 puede insertar la dirección de destino de SME recibida en el elemento de información SMS-SUBMIT TP-DA que se envía en el Mensaje 7.
En algunas implementaciones, para cada entrega de mensaje exitosa para datos originados en el móvil, el nodo 106 de red 1 puede crear un registro de detalle de llamada (CDR) con una indicación que puede incluir cualquiera o ninguno de los siguientes: tipo de datos recibidos (p. ej., SMS, USSD), tipo de datos dentro de ese tipo (p. ej., SMS-SUBMIT) o tamaño de los datos.
En algunas implementaciones, el número de mensajes a enviar y/o recibir por el EU antes de que el EU se separe o desconecte de la red puede incluir mensajes SMS que están marcados como mensajes SMS concatenados.
La Figura 3 es un diagrama de flujo de datos que ilustra un proceso 300 a modo de ejemplo para usar transporte optimizado de mensajes cortos para transferir datos originados en el móvil en un entorno CIoT según una implementación. El diagrama de flujo de datos incluye un EU 302, una estación base CIoT/Nodo B evolucionado (C-BS/eNB, por sus siglas en inglés) 304, un C-SGN 306, un SMSC/IWMSC 308, un HSS 310 y una pasarela 312 de red de datos por paquetes (P-GW, por sus siglas en inglés). C-BS/eNB 304 puede proveer conexión radioeléctrica con el EU 302. El C-SGN 306 puede ser el nodo 106 de red 1. El SMSC/IWMSC 308 puede ser el nodo 110 de red 3. El HSS 310 puede ser el nodo 108 de red 2. La P-GW 312 puede conectar el EU 302 con las diversas redes de datos externas como, por ejemplo, Internet. La Figura 3 ilustra el escenario en donde el EU 302 se conecta a la red para enviar datos originados en el móvil sin llevar a cabo una configuración de portadora y el EU 302 incluye los datos originados en el móvil en la PDU SMS.
En la operación 1, el EU 302 envía una conexión inicial con "SMS MO" para indicar que desea registrarse sin crear una conexión de red de datos por paquetes (PDN, por sus siglas en inglés) e incluye PDU SMS como se especifica en 3GPP TS 23.040, p. ej., Sm S-s Ub M iT. Esto sigue el procedimiento de conexión 3g PP TS 23.401 con un indicador adicional "SMS MO" para indicar que el EU desea conectarse sin establecer inmediatamente una conexión PDN e incluye una PDU SMS. El EU 302 puede iniciar un establecimiento de conexión de PDN en una etapa posterior si es necesario. El indicador “SMS MO” indica el servicio de datos de origen móvil.
En la operación 2, el C-SGN 306 procesa la conexión inicial e identifica que el EU no desea establecer una conexión PDN y desea enviar un SMS MO; por lo tanto, no sigue adicionalmente los procedimientos de conexión iniciales hacia la P-Gw 312 como se define en TS 23.401.
En la operación 3, el C-SGN 306 autentica el EU 302 siguiendo procedimientos normales.
En la operación 4, el C-SGN 306 lleva a cabo una actualización de ubicación al HSS 310 que incluye la razón para la actualización de ubicación, p. ej., SMS MO. Si el EU 302 está autorizado para llevar a cabo MO-SMS, entonces el HSS 310 enviará la información de suscripción al C-SGN 306 o enviará de vuelta un reconocimiento de actualización de ubicación con una indicación de que el EU 302 está autorizado para SMS MO.
En la operación 5, el C-SGN 306 establece el contexto de EU que indica al nodo RAN que se necesita portadora radioeléctrica de señalización (SRB, por sus siglas en inglés) y sin solicitar que se establezcan portadoras radioeléctricas de datos (DRB, por sus siglas en inglés)
En las operaciones 6 y 7, el mensaje de control de recursos radioeléctricos (RRC, por sus siglas en inglés) establece SRB.
En la operación 8, se reconoce el mensaje S1.
En la operación 9, el C-SGN 306 envía Rechazo de Conexión con "indicación que indica que se recibió y aceptó PDU SMS" al EU 302.
En la operación 10, el C-SGN 306 envía la PDU SMS usando procedimientos existentes al SMSC 308.
La Figura 4 es un diagrama de flujo de datos que ilustra un proceso 400 a modo de ejemplo para usar transporte optimizado de mensajes cortos para transferir datos terminados en el móvil en un entorno CIoT según una implementación. El diagrama de flujo de datos incluye un EU 302, una C-BS/eNB 304, un C-SGN 306, un SMSC/IWMSC 308, un HSS 310 y una P-GW 312. La FIGURA 4 ilustra el escenario en donde el EU 302 se conecta a la red para determinar si hay algún dato terminado en el móvil. La Figura 4 también ilustra el escenario en donde el EU 302 se conecta a la red para recibir datos terminados en el móvil sin llevar a cabo una configuración de portadora y los datos terminados en el móvil pueden encajar en un único mensaje.
En la operación 1, el EU 302 envía una conexión inicial con "MT SMS" para indicar que desea registrarse sin crear una conexión PDN. Esto sigue el procedimiento de conexión TS 23.401 con un indicador adicional "MT SMS" con el fin de indicar que el EU desea conectarse sin establecer inmediatamente una conexión PDN y desea que se entregue un SM pendiente. El EU 302 puede iniciar un establecimiento de conexión PDN en una etapa posterior si es necesario. El indicador “MT SMS” indica el servicio de datos de la terminación móvil.
En la operación 2, el C-SGN 306 procesa la conexión inicial e identifica que el EU 302 no desea establecer una conexión PDN y desea recibir MT SMS; por lo tanto, no sigue adicionalmente los procedimientos de conexión iniciales hacia la P-GW 312 como se define en TS 23.401.
En la operación 3, el C-SGN 306 autentica el EU 302 siguiendo procedimientos normales.
En la operación 4, el C-CCGN 306 lleva a cabo una Actualización de Ubicación al HSS 310 que incluye la razón para la Actualización de Ubicación, p. ej., MT SMS. Si el EU 302 está autorizado para llevar a cabo MT-SMS, entonces el HSS 310 informará al C-SGN 306 si hay o no hay mensajes pendientes que entregar. Si no hay mensajes, entonces se llevará a cabo la operación 12.
En la operación 5, el C-SGN 306 establece el contexto de EU que indica al nodo RAN que se necesita SRB y sin solicitar que se establezcan DRB.
En las operaciones 6 y 7, el mensaje RRC establece SRB.
En la operación 8, se reconoce el mensaje S1.
En la operación 9, el HSS 310 alerta al SMSC 308 de que el EU está disponible por procedimientos definidos en el 3GPP 29.002.
En la operación 10, el SMSC 308 envía la PDU SMS al C-SGN 306.
En la operación 11, cuando el C-SGN 306 recibe la PDU SMS del SMSC 308, el C-SGN 306 envía al EU 302 Rechazo de Conexión con inclusión de la PDU SMS, p. ej., SMS-DELIVER como se define en 3GPP TS 23.040.
En la operación 12, el C-SGN 306 envía un Rechazo de Conexión que incluye una indicación de que no hay mensajes a enviar.
La Figura 5 es un diagrama de flujo de datos que ilustra otro proceso 500 a modo de ejemplo para usar transporte optimizado de mensajes cortos para transferir datos terminados en el móvil en un entorno CIoT según una implementación. El diagrama de flujo de datos incluye un EU 302, una C-BS/eNB 304, un C-SGN 306, un SMSC/IWMSC 308, un HSS 310 y una P-GW 312. La Figura 5 ilustra el escenario en donde el EU 302 se conecta a la red para determinar si hay algún dato terminado en el móvil. La Figura 5 también ilustra el escenario en donde el EU 302 se conecta a la red para recibir datos terminados en el móvil sin llevar a cabo una configuración de portadora y los datos terminados en el móvil no pueden encajar en un único mensaje.
En la operación 1, el EU 302 envía una conexión inicial con "MT SMS" para indicar que desea registrarse sin crear una conexión PDN. Esto sigue el procedimiento de conexión TS 23.401 con un indicador adicional "MT SMS" con el fin de indicar que el EU desea conectarse sin establecer inmediatamente una conexión PDN y desea que se entregue un SM pendiente. El EU 302 puede iniciar un establecimiento de conexión PDN en una etapa posterior si es necesario. El indicador “MT SMS” indica el servicio de datos de la terminación móvil.
En la operación 2, el C-SGN 306 procesa la conexión inicial e identifica que el EU 302 no desea establecer una conexión PDN y desea recibir MT SMS; por lo tanto, no sigue adicionalmente los procedimientos de conexión iniciales hacia la P-GW 312 como se define en TS 23.401.
En la operación 3, el C-SGN 306 autentica el EU 302 siguiendo procedimientos normales.
En la operación 4, el C-SGN 306 lleva a cabo una Actualización de Ubicación al HSS 310 que incluye la razón para la Actualización de Ubicación, p. ej., MT SMS. El HSS 310 informará al C-SGN 306 que hay N mensajes que se enviarán al EU.
En la operación 5, el C-SGN 306 establece el contexto de EU que indica al nodo RAN que se necesita SRB y sin solicitar que se establezcan DRB.
En las operaciones 6 y 7, el mensaje RRC establece SRB.
En la operación 8, se reconoce el mensaje S1.
En la operación 9, el HSS 310 alerta al SMSC 308 de que el EU 302 está disponible parar procedimientos definidos en 3GPP 29.002.
En la operación 10a, el SMSC 308 envía la 1.a PDU SMS al C-SGN 306.
En la operación 10b, el SMSC 308 envía la 2.a PDU SMS al C-SGN 306.
En la operación 10n, el SMSC 308 envía la n-ésima PDU SMS al C-SGN 306. En algunas implementaciones, el SM puede proceder de numerosos SMS-C diferentes.
En la operación 11, cuando el C-SGN 306 recibe la 1.a PDU SMS del SMSC 308, el C-SGN 306 envía una Aceptación de Conexión que incluye la PDU SMS como se define en 3GPP TS 23.040 al EU 302 y una indicación del número de SM pendientes que se enviarán al EU 302.
En la operación 12, se llevan a cabo procedimientos SMS MO y MT siguiendo los procedimientos definidos en TS 23.060 mientras se utiliza la transferencia de datos pequeños descrita en otras secciones.
En la operación 13, cuando el EU 302 ha recibido el número de SM pendientes como se identifica en la operación 11 del C-SGN 306, el EU 302 enviará una Separación al C-SGN 306.
La Figura 6 es un diagrama esquemático que ilustra un proceso 600 a modo de ejemplo de un EU que incluye datos originados en el móvil en un Mensaje 1 según una implementación. El Mensaje 1 puede ser un mensaje de solicitud de conexión. Por ejemplo, el EU 102 incluye los datos originados en el móvil en el campo de datos 602 de usuario (UD, por sus siglas en inglés) de una PDU SMS-SUBMIT, e incluye además la PDU SMS-SUBMIT en el campo de longitud de datos de usuario (UDL, por sus siglas en inglés) y UD 608 del mensaje 610 de solicitud de conexión. El EU incluye la dirección SMSC en el campo de dirección 606 de destino (DA, por sus siglas en inglés) del mensaje 610 de solicitud de conexión. El mensaje 610 de solicitud de conexión que se enviará a un nodo de red 1 (p. ej., C-SGN) también incluye información 604 de conexión.
La Figura 7 es un diagrama esquemático que ilustra un proceso 700 a modo de ejemplo de un nodo de red 1 que extrae datos originados en el móvil de un Mensaje 1 y que incluye los datos en un Mensaje 7 según una implementación. El nodo de red 1 puede ser un C-SGN. El Mensaje 1 puede ser un mensaje de solicitud de conexión. El diagrama esquemático incluye un mensaje 702 de solicitud de conexión recibido del EU y un Mensaje 7710 para ser enviado a un nodo de red 3 (p. ej., SMS-C). Por ejemplo, el mensaje 702 de solicitud de conexión recibido en el C-SGN incluye la dirección SMSC incluida en el campo 704 de DA y los datos originados en el móvil incluidos en el campo 706 de UDL y UD. El C-SGN extrae los datos originados en el móvil del mensaje 702 de solicitud de conexión e incluye los datos en el campo 712 UD del Mensaje 7710. El mensaje 7710 también incluye la dirección SMSC en el campo 708 DA del campo 712 UD.
La Figura 8 es un diagrama esquemático que ilustra un proceso 800 a modo de ejemplo de un nodo de red 1 que extrae datos terminados en el móvil de un Mensaje 3c y que incluye los datos en un Mensaje 6 según una implementación. El nodo de red 1 puede ser un C-SGN. El Mensaje 6 puede ser un mensaje de respuesta de conexión, que puede ser un rechazo o aceptación de conexión. El diagrama esquemático incluye un Mensaje 3c 802 recibido desde un nodo de red 3 (p. ej., SMSC) y un mensaje 816 de respuesta de conexión para enviarse al EU. Por ejemplo, el Mensaje 3c 802 recibido del SMSC incluye un campo 804 UD. El campo 804 UD incluye además una PDU SMS-DELIVER con los datos terminados en el móvil incluidos en un campo 808 UD de la PDU SMS-DELIVER. El C-SGN extrae la PDU SMS-DELIVER del Mensaje 3c 802 e incluye la PDU en un campo 814 UDL y UD de un mensaje 816 de respuesta de conexión. El C-SGN también incluye la dirección SMSC en un campo 812 de dirección de originador (OA, por sus siglas en inglés) del mensaje 816 de respuesta de conexión. El C-SGN obtiene la dirección SMSC de un campo 806 de OA del campo 804 de UD en el Mensaje 3c 802. El mensaje 816 de respuesta de conexión incluye también información 810 de rechazo o aceptación de conexión.
La Figura 9 es un diagrama esquemático que ilustra un proceso 900 a modo de ejemplo de un EU que extrae datos terminados en el móvil de un Mensaje 6 según una implementación. El Mensaje 6 puede ser un mensaje de respuesta de conexión, que puede ser un rechazo o aceptación de conexión. Por ejemplo, el EU recibe un mensaje 902 de respuesta de conexión de un nodo de red 1 (p. ej., C-SGN). El mensaje 902 de respuesta de conexión puede incluir información 904 de rechazo o aceptación de conexión, la dirección SMSC en el campo 906 de OA y un campo 908 de UDL y UD. El campo 908 UDL y Ud puede incluir además una PDU SMS- DELIVER con los datos terminados en el móvil incluidos en un campo 910 UD de la PDU SMS-DELIVER. El EU extrae datos terminados en el móvil de la PDU SMS-DELIVER en el mensaje 902 de respuesta de conexión.
La Figura 10 es un diagrama esquemático que ilustra un proceso 1000 a modo de ejemplo de un EU que incluye datos originados en el móvil en un Mensaje 1 sin una dirección SMSC según una implementación. El Mensaje 1 puede ser un mensaje de solicitud de conexión. Por ejemplo, el EU incluye los datos originados en el móvil en el campo 1002 de datos de usuario (UD) de una PDU SMS-S<u>B<m>IT, e incluye además la PDU SMS-SUBMIT en el campo 1006 de longitud de datos de usuario (UDL) y UD del mensaje 1008 de solicitud de conexión. El EU no incluye una dirección SMSC en el mensaje 1008 de solicitud de conexión. El mensaje 1008 de solicitud de conexión que se enviará a un nodo de red 1 (p. ej., C-SGN) también incluye información 1004 de conexión.
La Figura 11 es un diagrama esquemático que ilustra un proceso 1100 a modo de ejemplo de un nodo de red 1 que extrae datos originados en el móvil de un Mensaje 1 y que incluye los datos en un Mensaje 7, sin que un EU proporcione una dirección SMSC, según una implementación. El nodo de red 1 puede ser un C-SGN. El Mensaje 1 puede ser un mensaje de solicitud de conexión. El diagrama esquemático incluye un mensaje 1102 de solicitud de conexión recibido del EU y un Mensaje 71108 a enviarse a un nodo de red 3 (p. ej., SMSC). Por ejemplo, el mensaje 1102 de solicitud de conexión recibido en el C-SGN incluye los datos originados en el móvil incluidos en el campo 1104 UDL y UD. El C-SGN extrae los datos originados en el móvil del mensaje 702 de solicitud de conexión e incluye los datos en el campo 1110 UD del Mensaje 71108. El mensaje 1102 de solicitud de conexión no incluye una dirección SMSC. El C-SGN puede incluir la dirección SMSC que se recibió del Mensaje 3e en el Mensaje 71108. Por ejemplo, la dirección SMSC puede incluirse en el campo 1106 DA del campo 1110<u>D del Mensaje 71108.
La Figura 12 es un diagrama esquemático que ilustra un proceso 1200 a modo de ejemplo de un nodo de red 1 que extrae datos terminados en el móvil de un Mensaje 3c e incluye los datos en un Mensaje 6 sin una dirección SMSc , según una implementación. El nodo de red 1 puede ser un C-SGN. El Mensaje 6 puede ser un mensaje de respuesta de conexión, que puede ser un rechazo o aceptación de conexión. El diagrama esquemático incluye un Mensaje 3c 1202 recibido de un nodo de red 3 (p. ej., SMSC) y un mensaje 1212 de respuesta de conexión que se enviará al EU. Por ejemplo, el Mensaje 3c 1202 recibido del SMS<c>incluye un campo 1204 UD. El campo 1204 UD incluye además una PDU SMS-DELIVER con los datos terminados en el móvil incluidos en un campo 1206 UD de la P<d>U SMS-DELIVER. El C-SGN extrae la PDU SMS-DELIVER del Mensaje 3c 1202 e incluye la PDU en un campo 1210 UDL y UD de un mensaje 1212 de respuesta de conexión. El C-SGN no incluye una dirección SMSC en el mensaje 1212 de respuesta de conexión. El mensaje 1212 de respuesta de conexión también incluye información 1208 de aceptación o rechazo de conexión.
La Figura 13 es un diagrama esquemático que ilustra un proceso 1300 a modo de ejemplo de un EU que extrae datos terminados en el móvil de un Mensaje 6 sin una dirección SMSC según una implementación. El Mensaje 6 puede ser un mensaje de respuesta de conexión, que puede ser un rechazo o aceptación de conexión. Por ejemplo, el EU recibe un mensaje 1302 de respuesta de conexión de un nodo de red 1 (p. ej., C-SGN). El mensaje 1302 de respuesta de conexión puede incluir información 1304 de aceptación o rechazo de conexión y un campo 1306 UDL y UD. El campo 1306 UDL y UD incluye además una PDU SMS-DELIVER con los datos terminados en el móvil incluidos en un campo 1308 UD de la PDU SMS-DELIVER. El EU extrae datos terminados en el móvil de la PDU SMS-DELIVER en el mensaje 1302 de respuesta de conexión. El mensaje 1302 de respuesta de conexión no incluye una dirección SMSC.
La Figura 14 es un diagrama de flujo que ilustra un método 1400 a modo de ejemplo para usar transporte de mensajes cortos optimizado para transferir datos en un entorno CIoT según una implementación. El método 1400 comienza en el bloque 1402, donde el primer nodo de red recibe un mensaje de solicitud de conexión de un EU. El mensaje de solicitud de conexión incluye datos de mensajes cortos e indica un tipo de servicio que el EU solicitó. Los datos de mensaje corto son una o más PDU que son al menos una de una<p>D<u>SMS-SUBMIT, una PDU SMS-COMMAND, una<p>D<u>SMS-DELIVER-REPORT o una PDU SMS-SUBMIT-REPORT. El tipo de servicio de datos puede ser uno de, entre otros, origen móvil, terminación móvil u origen y terminación móvil. En el bloque 1404, el primer nodo de red envía un mensaje a un segundo nodo de red y el mensaje indica el tipo de servicio que solicitó el E<u>.
En el bloque 1406, el primer nodo de red recibe un mensaje de respuesta de datos de mensajes cortos del segundo nodo de red. El mensaje de respuesta de datos de mensajes cortos incluye una dirección para un centro de servicio de mensajes cortos y puede incluir al menos una de una indicación que indica que no hay ningún mensaje terminado en el móvil pendiente para el EU, el número de mensajes terminados en el móvil pendientes para el EU, o una dirección de destino de entidad de mensajes cortos.
En el bloque 1408, el primer nodo de red transmite un mensaje de respuesta de conexión al EU. El mensaje de respuesta de conexión indica si un mensaje para el EU está pendiente y puede indicar el número de mensajes pendientes. El mensaje de respuesta de conexión también puede incluir el mensaje terminado en el móvil.
En el bloque 1410, el primer nodo de red determina el centro de servicio de mensajes cortos basándose en la dirección incluida en la respuesta de datos de mensajes cortos. En respuesta a la determinación, el primer nodo de red transmite los datos de mensajes cortos al centro de servicios de mensajes cortos.
La Figura 15 es un diagrama de flujo de datos que ilustra un proceso 1500 a modo de ejemplo para notificar a un nodo de red 2 una cantidad de mensajes terminados en el móvil pendientes según una implementación. El diagrama de flujo de datos incluye un nodo 108 de red 2 (p. ej., HSS) y un nodo 110 de red 3 (p. ej., SMSC).
En la operación 10, si un mensaje terminado en el móvil no puede entregarse al EU, el nodo 110 de red 3 puede enviar un Mensaje 10 al nodo 108 de red 2. El Mensaje 10 puede incluir la identidad del EU (p. ej., la identidad privada como, por ejemplo, IMSI o GUTI, o la identidad pública como, por ejemplo, MSISDN o URI) y/o el número de mensajes pendientes que se entregarán al EU. Al recibir el Mensaje 10, el nodo de red 2 puede almacenar la identidad del EU y/o el número de mensajes pendientes a entregarse. En la operación 11, el nodo 108 de red 2 puede enviar un Mensaje 11 al nodo 110 de red 3 para reconocer la recepción del Mensaje 10. En algunas implementaciones, el proceso 1500 a modo de ejemplo puede ocurrir cuando el EU no está conectado a la red.
Las Figuras 16A-16E ilustran una primera descripción a modo de ejemplo de procedimientos de gestión de movilidad del Sistema Evolucionado de Paquetes (EPS) (EMM) según una implementación. Por ejemplo, el procedimiento de conexión en 3GPP TS 24.302 puede incluir la siguiente descripción cuando el EU se conecta a la red para servicios SMS CIoT (también conocido como transporte optimizado de mensajes cortos):
Si el EU es capaz de CIoT, la red es capaz de CIoT (es preciso ver la descripción a continuación) y el EU quiere a) enviar un SM, entonces el EU enviará el mensaje ATTACH REQUEST (SOLICITUD DE CONEXIÓN) junto con el mensaje SMS-SUBMIT como se define en 3GPP 23.040 [x] contenido en el elemento de información de contenedor de mensajes CIoT. El EU establecerá el tipo de Conexión en "SMS MO".
b) recibir un SM, entonces el EU enviará el mensaje ATTACH REQUEST. El EU establecerá el tipo de Conexión en "SMS MT”; o
c) enviar y recibir un SM, entonces el EU enviará el mensaje ATTACH REQUEST junto con el mensaje SMS-SUBMIT como se define en 3GPP 23.040 [x] contenido en el elemento de información de contenedor de mensajes CIoT. El EU establecerá el tipo de Conexión en "SMS MO/MT".
Las Figuras 17A-17F ilustran una segunda descripción a modo de ejemplo de procedimientos EMM según una implementación. Por ejemplo, el procedimiento de conexión en 3GPP TS 24.302 puede incluir la siguiente descripción del comportamiento de<m>M<e>(es decir, el nodo de red 1) cuando la red acepta una solicitud de conexión de servicios SMS CIoT:
Si la red acepta la solicitud de conexión, la MME enviará un mensaje ATTACH ACCEPT (ACEPTACIÓN DE CONEXIÓN) al EU e iniciará el temporizador T3450. Si el EU indicó:
a) conexión EPS, conexión combinada de EPS/IMSI, entonces la MME enviará el mensaje ATTACH ACCEPT junto con un mensaje ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST (ACTIVAR SOLICITUD DE CONTEXTO DE PORTADORA DE EPS POR DEFECTO) contenido en el elemento de información de contenedor de mensajes ESM para activar la portadora por defecto (es preciso ver la subcláusula 6.4.1). La red también puede iniciar la activación de portadoras dedicadas hacia el EU invocando el procedimiento de activación del contexto de portadora dedicada EPS (es preciso ver la subcláusula 6.4.2).
b) SMS MO con el que la MME enviará un mensaje ATTACH REJECT (RECHAZO DE CONEXIÓN)
i) Si el EU indicó el tipo de Conexión a "SMS MO" y el elemento de información del contenedor de mensajes CloT contenía SMS PDU como se define en 3GPP TS 23.040 [x], el código de causa EMM se establece en
1) "Recepción exitosa de datos" si no hay mensajes pendientes para ser entregados al EU; o
2) "recepción exitosa de datos y mensajes pendientes de enviar" si hay mensajes pendientes de entregar al EU. ii) Si el EU indicó el tipo de Conexión a "SMS MO" y el elemento de información del contenedor de mensajes CloT no contiene una PDU de SMS como se define en 3GPP TS 23.040 [x] o el elemento de información contenido en el mensaje CloT no está presente, el código de causa EMM se establece en
1) "datos no recibidos" si no hay mensajes pendientes para ser entregados al EU; o
2) "datos no recibidos y datos pendientes de enviar" si hay mensajes pendientes de entregar al EU;
c) SMS MT con la que la MME enviará el mensaje ATTACH REJECT
i) Si el EU indicó el tipo de Conexión en "SMS MT", el código de causa de EMM se establece en "no hay mensajes terminados pendientes para enviar" si no hay mensajes pendientes para entregar al EU.
d) SMS MT con la que la MME enviará el mensaje ATTACH ACCEPT:
i) Si el EU indicó el tipo de Conexión en "SMS MT" y el código de causa de EMM se estableció en
1) "no hay mensajes terminados pendientes" si hay una única PDU MT de SMS como se define en 3GPP TS 23.040 [x] incluir la PDU MT de SMS como se define en 3GPP TS 23.040 [x] en el elemento de información del contenedor de mensajes CloT.
2) "mensajes pendientes para enviar" si hay más de una PDU MT de SMS como se define en 3GPP TS 23.040 [x] incluir la primera PDU MT de SMS como se define en 3GPP TS 23.040 [x] en el elemento de información del contenedor de mensajes CloT.
ALTERNATIVA A d)2)
d) SMS MT con la que la MME enviará el mensaje ATTACH ACCEPT
i) si hay una única PDU MT de SMS como se define en 3GPP TS 23.040 [x] incluir la PDU MT de SMS como se define en 3GP<p>TS 23.040 [x] en el elemento de información del contenedor de mensajes CloT.
ii) si hay más de una PDU MT de SMS como se define en 3GPP TS 23.040 [x] incluir
1) la primera PDU MT de SMS como se define en 3GPP TS 23.040 [x] en el elemento de información del contenedor de mensajes CloT; y el elemento de información Mensajes Pendientes con el número de mensajes pendientes a enviar. e) SMS MO/MT con la que la MME enviará un mensaje ATTACH REJECT
i) Si el EU indicó el tipo de Conexión en "SMS MO/MT" y el elemento de información del contenedor de mensajes CloT contenía SMS PDU como se define en 3GPP TS 23.040 [x], el código de causa EMM se establece en
1) "Recepción exitosa de datos" si no hay mensajes pendientes para ser entregados al EU; o
ALTERNATIVA A e)i1)
1) "recepción exitosa de datos y no hay mensajes pendientes para enviar" si no hay mensajes pendientes para entregar al EU; o
ii) si el EU indicó el tipo de Conexión en "SMS MO" y el elemento de información del contenedor de mensajes CloT no contiene una PDU de SMS como se define en 3GPp TS 23.040 [x] o el elemento de información del contenedor de mensajes CloT no está presente, el código de causa EMM se establece en
1) "datos no recibidos" si no hay mensajes pendientes para ser entregados al EU;
2) "datos no recibidos, mensajes pendientes por enviar" si hay mensajes pendientes por entregar al EU ALTERNATIVA A e)ii1)
1) "datos no recibidos, no hay mensajes pendientes para enviar" si no hay mensajes pendientes para entregar al EU; f) SMS MO/MT con la que la MME enviará un mensaje ATTACH ACCEPT
i) si el EU indicó el tipo de Conexión en "SMS MO/MT" y el elemento de información del contenedor de mensajes CloT contenía SMS PDU como se define en 3GPP TS 23.040 [x], el código de causa de EMM se establece en "Recepción exitosa de datos" y si hay
1) es una PDU MT de SMS única como se define en 3GPP TS 23.040 [x] incluir la PDU MT de SMS como se define en 3GPP TS 23.040 [x] en el elemento de información del contenedor de mensajes CloT.
2) si hay más de una PDU MT de SMS como se define en 3GPP TS 23.040 [x] incluir la primera PDU MT de SMS como se define en 3GPP TS 23.040 [x] en el elemento de información del contenedor de mensajes CloT; y el elemento de información Mensajes Pendientes con el número de mensajes pendientes a enviar
La Figura 18 ilustra una tercera descripción a modo de ejemplo de procedimientos EMM según una implementación. Por ejemplo, el procedimiento de conexión en 3GPP TS 24.302 puede incluir la siguiente descripción del comportamiento del EU cuando el EU recibe un mensaje de rechazo de conexión:
El EU deberá tomar las siguientes acciones dependiendo del valor de causa de EMM recibido en el mensaje ATTACH REJECT.
#3 (EU ilegal);
#6 (ME ilegal); o
#XX (datos no recibidos);
El EU repetirá el procedimiento ATTACH para el dispositivo CIoT hasta un número máximo de veces.
#XX (datos no recibidos, no hay mensajes pendientes para enviar);
El EU repetirá el procedimiento ATTACH y el EU establecerá el tipo de Conexión en "SMS MO".
#XX (datos no recibidos y datos pendientes de enviar);
El EU repetirá el procedimiento ATTACH y el EU establecerá el tipo de Conexión en "SMS MO/MT".
#XX (recepción exitosa de datos y mensajes pendientes de enviar);
El EU repetirá el procedimiento ATTACH y el EU establecerá el tipo de Conexión en "SMS MT".
Las Figuras 19A y 19B ilustran una descripción a modo de ejemplo de un mensaje de aceptación de conexión según una implementación. Por ejemplo, el mensaje de aceptación de conexión en 3GPP TS 24.302 puede incluir los siguientes elementos de información (IE):
Tabla 2: IE en el mensaje de aceptación de conexión
La Figura 20 ilustra una descripción a modo de ejemplo de un mensaje de rechazo de conexión según una implementación. Por ejemplo, el mensaje de rechazo de conexión en 3GPP TS 24.302 puede incluir el siguiente IE:
Tabla 3: IE en mensaje de rechazo de conexión
Las Figuras 21A y 21B ilustran una descripción a modo de ejemplo de un mensaje de solicitud de conexión según una implementación. Por ejemplo, el mensaje de solicitud de conexión en 3GPP TS 24.302 puede incluir el siguiente IE:
Tabla 4: IE en el mensaje de solicitud de conexión
Las Figuras 22A y 22B ilustran una descripción a modo de ejemplo de la causa de EMM según una implementación. Por ejemplo, las siguientes causas pueden incluirse en 3GPP TS 24.302:
Tabla 5: causas de EMM
La Figura 23 ilustra una descripción a modo de ejemplo del tipo de conexión de EPS según una implementación. Por ejemplo, el siguiente tipo de conexión EPS puede incluirse en 3GPP TS 24.302:
Tabla 6: elemento de información del tipo de conexión EPS
Tabla 7: valor del tipo de conexión EPS
Todos los demás valores no se utilizan y se interpretarán como "conexión EPS para CioT", si los recibe la red.
Bit 4 - 8 del octeto 2 son de repuesto y se codifican como cero
Otros valores pueden ser
1. Conexión SMS MO
2. Conexión SMS MT
3. Conexión SMS MO/MT
La Figura 24 ilustra una descripción a modo de ejemplo de un contenedor de mensajes CIoT según una implementación. Por ejemplo, la siguiente descripción del contenedor de mensajes CIoT puede incluirse en 3GPP TS 24.302:
Contenedor de mensajes CioT
El propósito del contenedor de mensajes CioT es transferir pequeños datos dentro de un mensaje EMM. Se definen los siguientes valores IEI:
Tabla 8: tipos de mensajes CIOT para la gestión de movilidad de EPS
La Figura 25 ilustra una descripción a modo de ejemplo del IE del contenedor de mensajes de datos según una implementación. Por ejemplo, la siguiente descripción del IE del contenedor de mensajes de datos puede incluirse en 3GPP TS 24.302:
Elemento de información del contenedor de mensajes de datos
El propósito del elemento de información del contenedor de mensajes de datos es permitir la transferencia de un mensaje de datos dentro de un mensaje EMM, p. ej., SMS o USSD. La carga útil de SMS se define en 3GPP TS 23.040. El mensaje SMS incluido en este IE se codificará como se especifica en la subcláusula 8.3, es decir, sin encabezado de seguridad NAS.
El elemento de información del contenedor de mensajes SMS está codificado como se muestra a continuación.
Tabla 9: elemento de información del contenedor de mensajes de datos
Tabla 10: descripción del elemento de información del contenedor de mensajes de datos Contenido del contenedor de mensajes SMS (octeto 4 a octeto n); Valor máximo de octetos YYY
Este IE puede contener cualquier PDU de SMS como se define en 3GPP TS 23.040.
La Figura 26 ilustra una descripción a modo de ejemplo de IE de mensajes pendientes según una implementación. Por ejemplo, la siguiente descripción de IE de mensajes pendientes puede incluirse en 3GPP TS 24.302:
Mensajes pendientes
El propósito de este elemento de información es indicar el número de mensajes a enviarse o recibirse por el EU.
Tabla 11: elemento de información de mensajes pendientes
Las Figuras 27A-27C ilustran una descripción a modo de ejemplo del servicio MAP_SEND_AUTHENTICATION_INFO según una implementación. Por ejemplo, las siguientes primitivas de servicio del servicio MAP_SEND_AUTHENTICATION_INFO pueden incluirse en 3GPP TS 29.002:
Tabla 12: parámetros MAP_SEND_AUTHENTICATION_INFO
Indicador de solo SMS
Este parámetro indica si el EU ha solicitado conectarse para enviar y/o recibir mensajes cortos.
O
Este parámetro indica si el EU ha solicitado conectarse para SMS.
Mensajes pendientes para enviar
Este parámetro estará presente si el HSS/HLR tiene conocimiento de uno o más mensajes cortos que deben enviarse al EU. Este parámetro estará ausente si el HSS/HLR no tiene conocimiento de ningún mensaje corto que deba enviarse al EU.
O:
Un número que indica cuántos mensajes cortos el EU estará preparado para recibir antes de llevar a cabo una desconexión de la red.
Las Figuras 28A-28C ilustran una descripción a modo de ejemplo del servicio MAP_UPDATE_LOCATION según una implementación. Por ejemplo, las siguientes primitivas de servicio del servicio MAP_UPDATE_LOCATION pueden incluirse en 3GPP TS 29.002:
Tabla 13: parámetros MAP_UPDATE_LOCATION
Indicador de solo SMS
Este parámetro indica si el EU ha solicitado conectarse para enviar y/o recibir mensajes cortos.
O
Este parámetro indica si el EU ha solicitado conectarse para SMS.
Mensajes pendientes para enviar
Este parámetro estará presente si el HSS/HLR tiene conocimiento de uno o más mensajes cortos que deben enviarse al EU. Este parámetro estará ausente si el HSS/HLR no tiene conocimiento de ningún mensaje corto que deba enviarse al EU.
O:
Un número que indica cuántos mensajes cortos el EU estará preparado para recibir antes de llevar a cabo una desconexión de la red.
Las Figuras 29A-29C ilustran una descripción a modo de ejemplo del servicio MAP_UPDATE_GPRS_LOCATION según una implementación. Por ejemplo, las siguientes primitivas de servicio del servicio MAP_UPDATE_GPRS_LOCATION pueden incluirse en 3GPP TS 29.002:
Tabla 14: parámetros MAP_UPDATE_GPRS_LOCATION
Indicador de solo SMS
Este parámetro indica si el EU ha solicitado conectarse para enviar y/o recibir mensajes cortos.
O
Este parámetro indica si el EU ha solicitado conectarse para SMS.
Mensajes pendientes para enviar
Este parámetro estará presente si el HSS/HLR tiene conocimiento de uno o más mensajes cortos que deben enviarse al EU. Este parámetro estará ausente si el HSS/HLR no tiene conocimiento de ningún mensaje corto que deba enviarse al EU.
O:
Un número que indica cuántos mensajes cortos el EU estará preparado para recibir antes de llevar a cabo una desconexión de la red.
Las Figuras 30A-30C ilustran una descripción a modo de ejemplo del servicio MAP-INSERT-SUBSCRIBER-DATA según una implementación. Por ejemplo, las siguientes primitivas de servicio del servicio MAP-INSERT-SUBSCRIBER-Da TA pueden incluirse en 3GPP TS 29.002:
Tabla 15: parámetro MAP-INSERT-SUBSCRIBER-DATA
Mensajes pendientes para enviar
Este parámetro estará presente si el HSS/HLR tiene conocimiento de uno o más mensajes cortos que deben enviarse al EU. Este parámetro estará ausente si el HSS/HLR no tiene conocimiento de ningún mensaje corto que deba enviarse al EU.
O:
Un número que indica cuántos mensajes cortos el EU estará preparado para recibir antes de llevar a cabo una desconexión de la red.
Las Figuras 31A y 31B ilustran una descripción a modo de ejemplo del servicio MAP-REPORT-SM-DELIVERY-STATUS según una implementación. Por ejemplo, las siguientes primitivas de servicio del servicio MAP-REPORT-SM-DELIVERY-STATUS pueden incluirse en 3GPP TS 29.002:
Tabla 16: parámetro MAP-REPORT-SM-DELIVERY-STATUS
Mensajes pendientes para enviar
Este parámetro estará presente si el HSS/HLR tiene conocimiento de uno o más mensajes cortos que deben enviarse al EU. Este parámetro estará ausente si el HSS/HLR no tiene conocimiento de ningún mensaje corto que deba enviarse al EU.
O:
Un número que indica cuántos mensajes cortos el EU estará preparado para recibir antes de llevar a cabo una desconexión de la red.
La Figura 32 ilustra una descripción a modo de ejemplo de un tipo de datos de servicio móvil según una implementación. Por ejemplo, la siguiente descripción del tipo de datos del servicio móvil puede incluirse en 3GPP TS 29.002:
Tabla 17: Descripción SendAuthenticationlnfoArg
Preferred [1] NULL
nlnfo Re-synchronisationlnfo
r [2] ExtensionContainer
e [3] RequestingNodeType
[4] PLMN-Id
Additional-’ ■rs [5] NumberOfRequestedVectors
AreForEPS [6] NULL
____________ ____[7]SMS-Onlylndicator }_____
Tabla 18: Descripción SMS-Onlylndicator
Si el IE "Mensajes pendientes para enviar" es una bandera/indicador simple:
Tabla 19: Descripción SendAuthenticationlnfoRes con una Bandera Simple de Mensajes
Pendientes
Si el IE "Mensajes pendientes para enviar" indica el número de mensajes que se enviarán al EU (p. ej., como se almacenan en el HSS/HLR):
Tabla 20: Descripción SendAuthenticationlnfoRes con un Número de Mensajes
Pendientes
Tabla 21: Descripción NumberOfPendingMessagesToSend
lNunberOfPendinqMessagesToSend :: integer (.. .M„-.xNumberOfPendinqMessagesToSend}Tabla 22: Descripción MaxNumberOfPendingMessagesToSend MaxNumberOfPendíngKessagesToSend ::= _____________
La Figura 33 es un esquema que ilustra un nodo 3300 de red a modo de ejemplo. El nodo 3300 de red a modo de ejemplo incluye un módulo 3302 de procesamiento, un subsistema 3304 de comunicación cableada y un subsistema 3306 de comunicación inalámbrica. El módulo 3302 de procesamiento puede incluir uno o más componentes de procesamiento (alternativamente denominados "procesadores" o "unidades centrales de procesamiento" (CPU, por sus siglas en inglés)) utilizables para ejecutar instrucciones asociadas a la gestión de comunicaciones entre dispositivos. El módulo 3302 de procesamiento también puede incluir otros componentes auxiliares como, por ejemplo, memoria de acceso aleatorio (RAM, por sus siglas en inglés), memoria de solo lectura (ROM, por sus siglas en inglés), almacenamiento secundario (por ejemplo, una unidad de disco duro o memoriaflash).El módulo 3302 de procesamiento puede ejecutar ciertas instrucciones y comandos para proveer comunicación inalámbrica o cableada, utilizando el subsistema 3304 de comunicación cableada o un subsistema 3306 de comunicación inalámbrica. Una persona con experiencia en la técnica apreciará fácilmente que también se pueden incluir otros componentes en el nodo 3300 de red a modo de ejemplo.
La Figura 34 es un esquema que ilustra un aparato de EU a modo de ejemplo. El EU 3400 a modo de ejemplo incluye una unidad 3402 de procesamiento, un medio 3404 de almacenamiento legible por ordenador (por ejemplo, ROM o memoriaflash),un subsistema 3406 de comunicación inalámbrica, una interfaz 3408 y una interfaz 3410 de E/S. El subsistema 3406 de comunicación inalámbrica puede configurarse para proveer comunicaciones inalámbricas para información de datos o información de control provista por la unidad 3402 de procesamiento. El subsistema 3406 de comunicación inalámbrica puede incluir, por ejemplo, una o más antenas, un receptor, un transmisor, un oscilador local, un mezclador y una unidad de procesamiento de señales digitales (DSP, por sus siglas en inglés). La interfaz 3408 puede incluir, por ejemplo, una o más de una pantalla o pantalla táctil (por ejemplo, una pantalla de cristal líquido (LCD, por sus siglas en inglés), una pantalla emisora de luz (LED, por sus siglas en inglés), una pantalla emisora de luz orgánica (OLED, por sus siglas en inglés), una pantalla de sistema microelectromecánico (MEMS, por sus siglas en inglés)), un teclado o teclado numérico, una bola de seguimiento, un altavoz y un micrófono. La interfaz 3410 de E/S puede incluir, por ejemplo, una interfaz de bus universal en serie (USB, por sus siglas en inglés). Una persona con experiencia en la técnica apreciará fácilmente que también se pueden incluir otros componentes en el dispositivo 3400 de EU a modo de ejemplo.
Si bien las operaciones se representan en los dibujos en un orden particular, esto no debe entenderse como que requiere que dichas operaciones se lleven a cabo en el orden particular que se muestra o en orden secuencial, o que se lleven a cabo todas las operaciones ilustradas, para lograr resultados deseables. En determinadas circunstancias, se puede emplear multitarea y procesamiento paralelo. Además, no debe entenderse que la separación de varios componentes del sistema en la implementación descrita anteriormente requiere dicha separación en todas las implementaciones, y debe entenderse que los componentes y sistemas del programa descritos generalmente pueden integrarse juntos en un producto de software de señal o empaquetarse en múltiples productos de software.
Además, las técnicas, sistemas, subsistemas y métodos descritos e ilustrados en las diversas implementaciones como discretos o separados pueden combinarse o integrarse con otros sistemas, módulos, técnicas o métodos. Otros elementos que se muestran o describen como acoplados o directamente acoplados o comunicándose entre sí pueden estar acoplados indirectamente o comunicándose a través de alguna interfaz, dispositivo o componente intermedio, ya sea de manera eléctrica, mecánica o de otro modo. Una persona con experiencia en la técnica puede determinar otros ejemplos de cambios, sustituciones y alteraciones que pueden llevarse a cabo.
Si bien la descripción detallada anterior ha mostrado, descrito y señalado las características novedosas fundamentales de la descripción aplicadas a diversas implementaciones, se entenderá que las personas con experiencia en la técnica pueden llevar a cabo diversas sustituciones y cambios en la forma y los detalles del sistema ilustrado. Además, el orden de las etapas del método no está implícito en el orden en que aparecen en las reivindicaciones.

Claims (9)

REIVINDICACIONES
1. Un método en un primer nodo (106) de red, que comprende:
recibir (1402), desde un equipo de usuario, EU (equipo de usuario) (102), un mensaje de solicitud de conexión, en donde el mensaje de solicitud de conexión incluye datos de mensaje corto formateados según una unidad de datos de protocolo, PDU, de servicio de mensajes cortos, SMS;
recibir (1406), de un segundo nodo (108) de red, un mensaje de respuesta de datos de mensajes cortos, en donde el mensaje de respuesta de datos de mensajes cortos incluye una dirección para un centro de servicios de mensajes cortos, SMSC (110, 308);
transmitir (1408) un mensaje de respuesta de conexión al EU (102), en donde el mensaje de respuesta de conexión indica si hay un mensaje pendiente para el EU; Y
determinar (1410) el centro de servicio de mensajes cortos basándose en la dirección incluida en la respuesta de datos de mensajes cortos; y
en respuesta a la determinación, transmitir los datos de mensajes cortos al centro (110, 308) de servicio de mensajes cortos.
2. El método de la reivindicación 1, en donde la unidad de datos de protocolo, PDU, del servicio de mensajes cortos, SMS, es una de una PDU SMS-SUBMIT, una PDU SMS-COMMAND, una PDU SMS-DELIVER-REPORT y una PDU SMS-SUBMIT-REPORT.
3. El método de la reivindicación 1, en donde el mensaje de solicitud de conexión indica un tipo de servicio para transmitir los datos de mensajes cortos.
4. El método de la reivindicación 1, en donde el mensaje de solicitud de conexión indica que el EU solicita no pasar al modo conectado.
5. El método de la reivindicación 1, que comprende además:
enviar un segundo mensaje al segundo nodo de red, en donde el segundo mensaje indica un tipo de servicio para transmitir los datos de mensajes cortos.
6. El método de la reivindicación 5, en donde el segundo mensaje es al menos uno de una solicitud de autenticación y una actualización de ubicación.
7. El método de la reivindicación 1, en donde el mensaje de respuesta de datos de mensajes cortos comprende una inserción de datos de abonado, ISD.
8. Un nodo (106) de red, que comprende:
una memoria; y
al menos un procesador de hardware acoplado comunicativamente a la memoria y configurado para:
llevar a cabo las etapas del método de las reivindicaciones 1 a 7.
9. Un medio tangible, no transitorio y legible por ordenador que contiene instrucciones que, cuando se ejecutan, hacen que un nodo (106) de red lleve a cabo las etapas del método de las reivindicaciones 1 a 7.
ES16753920T 2015-08-24 2016-08-19 Transporte optimizado de mensajes cortos Active ES2984383T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/834,216 US9769592B2 (en) 2015-08-24 2015-08-24 Optimized short message transport
PCT/EP2016/069692 WO2017032707A1 (en) 2015-08-24 2016-08-19 Optimized short message transport

Publications (1)

Publication Number Publication Date
ES2984383T3 true ES2984383T3 (es) 2024-10-29

Family

ID=56740241

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16753920T Active ES2984383T3 (es) 2015-08-24 2016-08-19 Transporte optimizado de mensajes cortos

Country Status (7)

Country Link
US (4) US9769592B2 (es)
EP (2) EP4311322A3 (es)
JP (1) JP6908597B2 (es)
KR (2) KR102686743B1 (es)
CN (1) CN108141719B (es)
ES (1) ES2984383T3 (es)
WO (1) WO2017032707A1 (es)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9769592B2 (en) 2015-08-24 2017-09-19 Blackberry Limited Optimized short message transport
US10270892B2 (en) * 2015-09-21 2019-04-23 Acer Incorporated Apparatuses and methods for handling mobile originated (MO) cellular internet of things (CIoT) data
ES2912279T3 (es) * 2015-11-06 2022-05-25 Alcatel Lucent Soporte de entrega de mensajes cortos terminados en móvil para un equipo de usuario en DRX en modo inactivo
CN106961722B (zh) * 2016-01-12 2018-09-11 展讯通信（上海）有限公司 数据的传输方法及基站
EP3403467B1 (en) * 2016-01-14 2020-07-22 LG Electronics Inc. -1- Method for connecting with network at ue in wireless communication system and apparatus therefor
US10623914B2 (en) * 2016-02-17 2020-04-14 Tracfone Wireless, Inc. Device, system, and process for providing real-time short message data services for mission critical communications
US20170289791A1 (en) * 2016-04-05 2017-10-05 Electronics And Telecommunications Research Institute Communication method and apparatus using network slice
EP3244660B1 (en) * 2016-05-10 2018-11-07 HTC Corporation Handling network feature
GB2565985A (en) * 2016-07-11 2019-02-27 Motorola Solutions Inc Method and apparatus for disassociating from a network
US10701112B2 (en) * 2016-08-05 2020-06-30 T-Mobile Usa, Inc. IP-based USSD communications
JP6971118B2 (ja) * 2017-10-10 2021-11-24 株式会社ソラコム ＩｏＴ機器とのデータの送受信を行うための装置、方法及びプログラム
US12457205B2 (en) * 2017-11-20 2025-10-28 Marc Lauren Abramowitz System and method for block chain encrypted communication and identification
US10484844B2 (en) * 2017-12-27 2019-11-19 Nokia Solutions And Networks Oy Simplified short message service (SMS) procedure for communication with internet of things devices
WO2019193133A1 (en) * 2018-04-06 2019-10-10 Blackberry Limited Increasing battery performance for a device that uses power saving features
KR102261236B1 (ko) 2018-04-17 2021-06-04 주식회사 엘지화학 격벽 패턴 필름 및 이의 제조방법
US10764938B2 (en) * 2018-08-22 2020-09-01 Verizon Patent And Licensing Inc. Systems and methods for managing small data over a non-access stratum
CN109246631B (zh) * 2018-11-29 2022-03-15 中电万维信息技术有限责任公司 一种短信发送的方法
EP3949669A4 (en) * 2019-04-02 2023-01-04 Nokia Technologies Oy METHOD AND DEVICE FOR DATA TRANSMISSION OF CELLULAR INTERNET OF THINGS (CIOT) THROUGH A CONTROL PLANE IN A WIRELESS COMMUNICATION SYSTEM
CN112584332A (zh) * 2019-09-29 2021-03-30 中兴通讯股份有限公司 短消息传输方法、装置和系统、注册方法和装置
US20220408229A1 (en) * 2021-06-18 2022-12-22 At&T Intellectual Property I, L.P. Land mobile radio and mission critical push to talk interworking
CN113423077B (zh) * 2021-07-09 2022-10-25 哈尔滨海能达科技有限公司 专网下信息的发送方法、接收方法及相关装置
TWI793697B (zh) * 2021-08-03 2023-02-21 緯創資通股份有限公司 恆在協定資料單元會話之增強信令方法及使用者裝置

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7043233B2 (en) * 2001-04-27 2006-05-09 Comverse, Inc. Messaging protocol over internet protocol
JP4734240B2 (ja) * 2003-06-18 2011-07-27 インテリシンク コーポレイション リモート装置に通知を提供するシステムと方法
US7715856B2 (en) * 2004-06-02 2010-05-11 Interdigital Technology Corporation Reporting terminal capabilities for supporting short message service
EP2182328A1 (en) * 2008-10-28 2010-05-05 Koninklijke KPN N.V. Telecommunications network and method of transferring user data in signalling messages from a communication unit to a data processing centre
KR101556906B1 (ko) * 2008-12-29 2015-10-06 삼성전자주식회사 선인증을 통한 이종 무선 통신망 간의 핸드오버 방법
CN102396284B (zh) * 2009-10-30 2015-05-06 华为技术有限公司 用于传输净负荷数据的方法和设备
CN102083048B (zh) * 2010-02-10 2014-12-03 电信科学技术研究院 空闲状态信令优化激活状态下寻呼消息的处理方法及设备
US9973877B2 (en) * 2011-09-23 2018-05-15 Htc Corporation Method of handling small data transmission
WO2013051827A2 (en) * 2011-10-03 2013-04-11 Lg Electronics Inc. Mobility management entity having mobile switching center functionality
JP5944004B2 (ja) * 2011-10-03 2016-07-05 インテル・コーポレーション デバイスツーデバイス通信（ｄ２ｄ通信）メカニズム
WO2013085310A1 (en) * 2011-12-06 2013-06-13 Samsung Electronics Co., Ltd. Apparatus and method for delivering short message service efficiently in wireless communication system
KR101554219B1 (ko) * 2012-03-09 2015-09-21 주식회사 케이티 이동통신망에서 패킷 교환 전용 가입을 위한 단문 메시지 서비스 제공 방법 및 장치
US20140241241A1 (en) * 2013-02-28 2014-08-28 Alcatel-Lucent Usa, Inc. Method and apparatus for supporting short message services for packet switched devices
US9078109B2 (en) * 2012-04-09 2015-07-07 Intel Corporation Frame structure design for new carrier type (NCT)
US9014730B2 (en) * 2012-06-28 2015-04-21 Alcatel Lucent Device reachability in LTE networks for text messaging
EP2961212B1 (en) * 2014-06-23 2020-09-09 Samsung Electronics Co., Ltd Method and apparatus for providing a sponsored data service to a user
US9948519B2 (en) * 2015-08-14 2018-04-17 Telefonaktiebolaget Lm Ericsson (Publ) Systems and methods for establishing a packet data network connection for a wireless communication device
US20170048684A1 (en) * 2015-08-14 2017-02-16 Telefonaktiebolaget L M Ericsson (Publ) Methods, devices, and nodes for optimized short message service relay for cellular internet-of-things
US9769592B2 (en) 2015-08-24 2017-09-19 Blackberry Limited Optimized short message transport

Also Published As

Publication number Publication date
US10979880B2 (en) 2021-04-13
JP6908597B2 (ja) 2021-07-28
KR102686743B1 (ko) 2024-07-19
WO2017032707A1 (en) 2017-03-02
EP3320706A1 (en) 2018-05-16
EP3320706B1 (en) 2024-04-17
KR20180044325A (ko) 2018-05-02
US20190174282A1 (en) 2019-06-06
CN108141719A (zh) 2018-06-08
CA2996449A1 (en) 2017-03-02
US20200154252A1 (en) 2020-05-14
US20170064487A1 (en) 2017-03-02
US10560828B2 (en) 2020-02-11
US9769592B2 (en) 2017-09-19
US20170347225A1 (en) 2017-11-30
EP4311322A3 (en) 2024-04-10
JP2018529281A (ja) 2018-10-04
EP3320706C0 (en) 2024-04-17
EP4311322A2 (en) 2024-01-24
HK1253884A1 (zh) 2019-07-05
CN108141719B (zh) 2021-12-21
KR20230131952A (ko) 2023-09-14
KR102574662B1 (ko) 2023-09-04
US10200841B2 (en) 2019-02-05

Similar Documents

Publication Publication Date Title
ES2984383T3 (es) Transporte optimizado de mensajes cortos
EP2709291B1 (en) Method and apparatus for mtc in a wireless communication system
US10136269B2 (en) Mobility management entity having mobile switching center functionality
US9072075B2 (en) Method of handling emergency bearer service in wireless communication system
EP2451203B1 (en) Method of handling queries caused overload in wireless communication system
US20150282120A1 (en) User equipment, base station, and mtc-iwf for implementing group based mtc messaging through cell broadcast
US9426687B2 (en) Method of handling non-access stratum message and related communication device
ES2912387T3 (es) Servicio de mensajes cortos sobre estrato sin acceso con modelo de encaminamiento doméstico
CN102026122A (zh) 处理无线通讯系统紧急短讯服务的方法及其相关装置
US9603037B2 (en) Method of handling delayed signaling of target mobile device
CA2996449C (en) Optimized short message transport
HK1253884B (zh) 优化的短消息传输
HK1224486B (zh) 移动台被叫紧急呼叫