ES2952593T3 - Métodos y aparatos para la entrega de SMS - Google Patents

Métodos y aparatos para la entrega de SMS Download PDF

Info

Publication number
ES2952593T3
ES2952593T3 ES20781499T ES20781499T ES2952593T3 ES 2952593 T3 ES2952593 T3 ES 2952593T3 ES 20781499 T ES20781499 T ES 20781499T ES 20781499 T ES20781499 T ES 20781499T ES 2952593 T3 ES2952593 T3 ES 2952593T3
Authority
ES
Spain
Prior art keywords
sms
terminal device
entity
context
udr
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
ES20781499T
Other languages
English (en)
Inventor
Hongxia Long
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2952593T3 publication Critical patent/ES2952593T3/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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/06—Registration at serving network Location Register, VLR or user mobility server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • 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/18—Service support devices; Network management devices
    • H04W88/184—Messaging devices, e.g. message centre

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)
  • Telephonic Communication Services (AREA)
  • Vending Machines For Individual Products (AREA)
  • Infusion, Injection, And Reservoir Apparatuses (AREA)
  • Pharmaceuticals Containing Other Organic And Inorganic Compounds (AREA)

Abstract

Se describen métodos y aparatos para la entrega de servicios de mensajes cortos (SMS). Según una realización, una entidad de gestión unificada de datos (UDM) mantiene un contexto de espera de servicio de mensajes cortos (SMS) para un dispositivo terminal. El contexto de espera de SMS es información relacionada con un nuevo intento de entrega de SMS de terminación móvil (MT) desde al menos un centro de servicio de SMS (SMS-SC) al dispositivo terminal debido a un fallo en la entrega de SMS de MT. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Métodos y aparatos para la entrega de SMS
Campo técnico
Las realizaciones de la descripción se refieren en general a la comunicación y, más particularmente, a métodos y aparatos para la entrega de SMS.
Antecedentes
Esta sección introduce aspectos que pueden facilitar una mejor comprensión de la presente descripción. En consecuencia, las declaraciones de esta sección deben leerse bajo esta luz y no deben entenderse como admisiones sobre lo que está en el estado actual de la técnica o lo que no está en el estado actual de la técnica.
De acuerdo con la sección 4.4.2 de la especificación técnica (TS, por sus siglas en inglés) 23.501 VI 6.3.0 del proyecto de asociación de tercera generación (3GPP, por sus siglas en inglés), el servicio de mensajes cortos (SMS, por sus siglas en inglés) se puede implementar a través del estrato sin acceso (NAS, por sus siglas en inglés). La Figura 1 muestra la arquitectura sin itinerancia para soportar SMS a través de NAS utilizando interfaces basadas en servicios dentro del plano de control. Como se muestra, la arquitectura comprende un equipo de usuario (UE, por sus siglas en inglés), una función de gestión de acceso y movilidad (AMF, por sus siglas en inglés), una función de SMS (SMSF, por sus siglas en inglés), una gestión de datos unificados (UDM, por sus siglas en inglés), una pasarela de mensajes cortos de protocolo de Internet (IP) (IP- SM-GW, por sus siglas en inglés), y un centro de conmutación móvil de pasarela de SMS (SMS-GMSC, por sus siglas en inglés)/centro de conmutación móvil de interfuncionamiento (IWMSC, por sus siglas en inglés)/rúter SMS. El término Nsmsf se refiere a una interfaz basada en servicios presentada por la SMSF.
La Figura 2 muestra la arquitectura sin itinerancia para soportar SMS a través de NAS mediante el uso de representación de puntos de referencia. N1 es el punto de referencia para la transferencia de SMS entre UE y AMF a través de NAS. Los siguientes puntos de referencia se realizan mediante interfaces basadas en servicios: N8, que es el punto de referencia para la recuperación de datos de suscripción de SMS entre AMF y UDM; N20, que es el punto de referencia para la transferencia de SMS entre AMF y SMSF; y N21, que es el punto de referencia para la gestión de registro de direcciones de SMSF y la recuperación de datos de suscripción de gestión de SMS entre SMSF y UDM. La Figura 3 muestra la arquitectura de itinerancia para soportar SMS a través de NAS utilizando interfaces basadas en servicios dentro del plano de control. El término HPLMN se refiere a la red móvil terrestre pública (PLMN, por sus siglas en inglés) doméstica y VPLMN se refiere a la PLMN visitada. La Figura 4 muestra la arquitectura de itinerancia para soportar SMS a través de NAS mediante el uso de representación de puntos de referencia. Téngase en cuenta que el repositorio de datos unificados (UDR, por sus siglas en inglés) no se muestra en las Figuras 1 -4 por brevedad.
El documento 3GPP TS 23.502 V15.3.0 describe los procedimientos de Etapa 2 y Servicios de Funciones de Red para la arquitectura del sistema 5G descrita en 3GPP TS 23.501: “System Architecture for the 5G System; Stage 2” y para el marco de control de políticas y tarificación descrito en 3GPP TS 23.503: “Policy and Charging Control Framework for the 5G System”.
El documento “Pseudo-CR on UDICOM SMS”, Nokia et. Al., borrador 3GPP, C4-192405, describe una propuesta para añadir flujos de SMS a especificaciones técnicas existentes.
El documento “Pseudo-CR on SMS Procedures”, Ericsson, borrador 3GPP, C4-195429, describe actualizaciones a los procedimientos de interfuncionamiento UDICOM para soporte de SMS con el fin de completar y alinearse con especificaciones SA2 relativas al soporte de reintento de entrega de MT-SMS cuando el UE no está registrado en SMSF.
El documento 3GPP TS 29.504 V16.2.0 describe el protocolo de etapa 3 y modelo de datos de alto nivel para la Interfaz Basada en Servicio Nudr. Proporciona definiciones de protocolo de etapa 3 y flujos de mensajes, y especifica la API para cada servicio ofrecido por el Repositorio de Datos Unificados (UDR). El modelo de datos y el uso de los datos de suscripción están especificados en 3GPP TS 29.505: “5G System; Usage of the Unified Data Repository Services for Subscription Data; Stage 3”, y el modelo de datos y el uso de los datos de políticas, datos estructurados para datos de exposición y aplicación están especificados en 3GPP TS 29.519: “5G System; Usage of the Unified Data Repository Service for Policy Data, Structured Data for Exposure and Application Data; Stage 3”.
Compendio
Este compendio se proporciona para introducir una selección de conceptos en una forma simplificada que se describen más abajo en la descripción detallada. Este compendio no pretende identificar características clave o características esenciales del objeto reivindicado, ni pretende ser utilizado para limitar el alcance del objeto reivindicado.
De acuerdo con la presente descripción se proporcionan métodos, una entidad UDM, una entidad UDR y un medio de almacenamiento legible por ordenador de acuerdo con las reivindicaciones independientes. En las reivindicaciones dependientes se exponen desarrollos.
Uno de los objetos de la descripción consiste en proporcionar una solución mejorada para la entrega de SMS.
Según un primer aspecto de la descripción se proporciona un método realizado por una entidad de gestión de datos unificados (UDM). El método puede comprender transmitir una solicitud HTTP a una entidad de repositorio de datos unificados, UDR, para mantener un contexto de espera de servicio de mensajes cortos (SMS) para un dispositivo terminal, en la entidad UDR. El contexto de espera de SMS puede consistir en información relacionada con un reintento de entrega de SMS con terminación en móvil (MT, por sus siglas en inglés) desde al menos un centro de servicio de SMS (SMS-SC, por sus siglas en inglés) al dispositivo terminal debido a un fallo en la entrega de MT SMS.
De este modo, cuando se puede iniciar el reintento de entrega de MT SMS, éste puede ser activado por la entidad UDM ya que se mantiene el contexto de espera de SMS.
En una realización de la descripción, el contexto de espera de SMS se puede mantener mediante al menos una de las siguientes etapas: consultar a la entidad UDR sobre un contexto de espera de SMS para el dispositivo terminal; crear un contexto de espera de SMS para el dispositivo terminal; y actualizar el contexto de espera de SMS para el dispositivo terminal.
En una realización de la descripción, la consulta se puede realizar enviando una solicitud GET del protocolo de transferencia de hipertexto (HTTP, por sus siglas en inglés) a la entidad UDR. La creación se puede realizar enviando una solicitud HTTP PUT a la entidad UDR. La actualización se puede realizar enviando una solicitud HTTP a la entidad UDR.
En una realización de la descripción, la solicitud HTTP PUT puede comprender el contexto de espera de SMS para el dispositivo terminal. Alternativa o adicionalmente, la solicitud HTTP PATCH puede comprender una indicación que indica al menos uno de los contextos de espera de SMS para el dispositivo terminal.
En una realización de la descripción, el método puede comprender además recibir una respuesta HTTP GET en respuesta a una solicitud HTTP GET, en donde la respuesta HTTP GET puede comprender el contexto de espera de SMS para el dispositivo terminal.
En una realización de la descripción, el método puede comprender además alertar al, al menos un, SMS-SC de que el reintento de la entrega de MT SMS se puede iniciar para el dispositivo terminal, sobre la base del contexto de espera de SMS mantenido.
En una realización de la descripción, el método puede comprender además eliminar el contexto de espera de SMS mantenido después de alertar al, al menos un, SMS-SC.
En una realización de la descripción, el contexto de espera de SMS mantenido se puede eliminar de una entidad UDR.
En una realización de la descripción, la eliminación se puede realizar enviando una solicitud HTTP DELETE a la entidad UDR.
En una realización de la descripción, el contexto de espera de SMS para el dispositivo terminal puede incluir al menos uno de: una lista de una dirección del al menos un SMS-SC; una lista de un tiempo de caducidad del al menos un SMS-SC hasta el cual es válido el reintento de la entrega del MT SMS por parte del al menos un SMS-SC; un primer indicador que indica que un motivo para el fallo de la entrega de MT SMS consiste en que el dispositivo terminal no está accesible; un segundo indicador que indica que el motivo del fallo de la entrega de MT SMS consiste en que se ha excedido la capacidad de memoria del dispositivo terminal; un tercer indicador que indica un motivo para el reintento de la entrega del MT SMS; un primer punto en el tiempo hasta el cual es válido el reintento de la entrega del MT SMS; y un segundo punto en el tiempo hasta el cual es válido el segundo indicador.
En una realización de la descripción, el tercer indicador puede tener un primer valor que indica que el dispositivo terminal está accesible para el reintento, y/o un segundo valor que indica que el dispositivo terminal tiene memoria disponible para el reintento.
En una realización de la descripción, mantener el contexto de espera de SMS en la entidad UDR para el dispositivo terminal puede comprender al menos una de las siguientes etapas: en respuesta a la recepción de una información sobre un fallo en la entrega de MT SMS, consultar a la entidad UDR sobre un contexto de espera de SMS para el dispositivo terminal; cuando no ha habido un contexto de espera de SMS almacenado en la entidad UDR para el dispositivo terminal, crear un contexto de espera de SMS en la entidad UDR para el dispositivo terminal; y cuando ha habido un contexto de espera de SMS almacenado en la entidad UDR para el dispositivo terminal y el fallo de la entrega de MT SMS está relacionado con un SMS-SC diferente al del contexto de espera de SMS, actualizar el contexto de espera de SMS en la entidad UDR para el dispositivo terminal.
En una realización de la descripción, la entidad UDM puede ser informada de que el motivo del fallo de la entrega de MT SMS consiste en que el dispositivo terminal no está accesible. El contexto de espera de SMS creado o actualizado puede incluir el primer indicador.
En una realización de la descripción se puede informar a la entidad UDM de que el motivo del fallo de la entrega de MT SMS consiste en que se ha excedido la capacidad de memoria del dispositivo terminal. El contexto de espera de SMS creado o actualizado puede incluir el segundo indicador.
En una realización de la descripción, mantener el contexto de espera de SMS en la entidad UDR para el dispositivo terminal puede comprender, en respuesta a un evento que indica que se puede iniciar el reintento, consultar a la entidad UDR sobre el contexto de espera de SMS para el dispositivo terminal. Mantener el contexto de espera de SMS en la entidad UDR para el dispositivo terminal puede comprender además actualizar el contexto de espera de SMS en la entidad UDR para el dispositivo terminal.
En una realización de la descripción, el evento puede consistir en que se informe a la entidad UDM de que se puede acceder al dispositivo terminal. El contexto de espera de SMS consultado incluye el primer indicador y no incluye el segundo indicador. El contexto de espera de SMS se puede actualizar en la entidad UDR eliminando el primer indicador del contexto de espera de SMS.
En una realización de la descripción, el evento puede consistir en que se informe a la entidad UDM de que el dispositivo terminal tiene memoria disponible para el reintento. El contexto de espera de SMS consultado incluye el segundo indicador y no incluye el primer indicador. El contexto de espera de SMS se puede actualizar en la entidad UDR eliminando el segundo indicador del contexto de espera de SMS.
En una realización de la descripción, el evento puede consistir en que se informe a la entidad UDM de que el dispositivo terminal está accesible o tiene memoria disponible para el reintento. El contexto de espera de SMS consultado no incluye el primer indicador ni el segundo indicador. El contexto de espera de SMS se puede actualizar en la entidad UDR agregando el tercer indicador y el primer punto en el tiempo en el contexto de espera de SMS.
Según un segundo aspecto de la descripción se proporciona un método realizado por una entidad UDR. El método puede comprender mantener, para un dispositivo terminal, un contexto de espera de SMS en respuesta a una solicitud HTTP procedente de una entidad UDM. El contexto de espera de SMS puede consistir en información relacionada con un reintento de una entrega de MT SMS desde al menos un SMS-SC al dispositivo terminal debido a un fallo en la entrega de MT SMS.
En una realización de la descripción, el contexto de espera de SMS se puede mantener mediante al menos una de las siguientes etapas: responder a una consulta procedente de la entidad UDM sobre un contexto de espera de SMS para el dispositivo terminal; crear un contexto de espera de SMS para el dispositivo terminal; y actualizar el contexto de espera de SMS para el dispositivo terminal.
En una realización de la descripción, la consulta puede consistir en una solicitud HTTP GET. La creación se puede realizar recibiendo una solicitud HTTP PUT procedente de la entidad UDM. La actualización se puede realizar recibiendo una solicitud HTTP PUT o PATCH de la entidad UDM.
En una realización de la descripción, el método puede comprender además eliminar el contexto de espera de SMS mantenido en respuesta a otra solicitud procedente de la entidad UDM.
En una realización de la descripción, la eliminación se puede realizar mediante la recepción de una solicitud HTTP DELETE procedente de la entidad UDM.
En una realización de la descripción, el contexto de espera de SMS para el dispositivo terminal puede incluir al menos uno de: una lista de una dirección del al menos un SMS-SC; una lista de un tiempo de caducidad del al menos un SMS-SC hasta el cual es válido el reintento de la entrega del MT SMS por parte del al menos un SMS-SC; un primer indicador que indica que un motivo para el fallo de la entrega de MT SMS consiste en que el dispositivo terminal no está accesible; un segundo indicador que indica que el motivo del fallo de la entrega de MT SMS consiste en que se ha excedido la capacidad de memoria del dispositivo terminal; un tercer indicador que indica un motivo para el reintento de la entrega del MT SMS; un primer punto en el tiempo hasta el cual es válido el reintento de la entrega del MT SMS; y un segundo punto en el tiempo hasta el cual es válido el segundo indicador.
En una realización de la descripción, el tercer indicador puede tener un primer valor que indica que el dispositivo terminal está accesible para el reintento, y/o un segundo valor que indica que el dispositivo terminal tiene memoria disponible para el reintento.
Según un tercer aspecto de la descripción se proporciona un método implementado en un sistema de comunicación que incluye una entidad UDM y una entidad UDR. El método puede comprender transmitir una solicitud HTTP a la entidad UDR para mantener, por medio de la entidad UDM, un contexto de espera de SMS en la entidad UDR para un dispositivo terminal. El contexto de espera de SMS puede consistir en información relacionada con un reintento de una entrega de MT SMS procedente de al menos un SMS-SC al dispositivo terminal debido a un fallo en la entrega de MT SMS. La entidad UDR puede mantener, para el dispositivo terminal, el contexto de espera de SMS en respuesta a una solicitud HTTP procedente de la entidad UDM.
Según un cuarto aspecto de la descripción se proporciona una entidad UDM. La entidad UDM puede comprender al menos un procesador y al menos una memoria. La al menos una memoria puede contener Instrucciones ejecutables por el al menos un procesador, por lo que la entidad UDM puede estar operativa para transmitir una solicitud HTTP a la entidad UDM para mantener un contexto de espera de SMS para un dispositivo terminal, en la entidad UDM. El contexto de espera de SMS puede consistir en información relacionada con un reintento de una entrega de MT SMS desde al menos un SMS-SC al dispositivo terminal debido a un fallo en la entrega de MT SMS.
En una realización de la descripción, la entidad UDM puede ser operativa para realizar el método de acuerdo con el anterior primer aspecto.
Según un quinto aspecto de la descripción se proporciona una entidad UDR. La entidad UDR puede comprender al menos un procesador y al menos una memoria. La al menos una memoria puede contener instrucciones ejecutables por el al menos un procesador, por lo que la entidad UDR puede estar operativa para mantener, para un dispositivo terminal, un contexto de espera de SMS en respuesta a una solicitud HTTP procedente de una entidad UDM. El contexto de espera de SMS puede consistir en información relacionada con un reintento de una entrega de MT SMS desde al menos un SMS-SC al dispositivo terminal debido a un fallo en la entrega de MT SMS.
En una realización de la descripción, la entidad UDR puede ser operativa para realizar el método de acuerdo con el anterior segundo aspecto.
Según un sexto aspecto de la descripción se proporciona un producto de programa informático. El producto de programa informático puede comprender instrucciones que, cuando son ejecutadas por al menos un procesador, hacen que al menos un procesador realice el método de acuerdo con cualquiera de los anteriores aspectos primero y segundo.
Según un séptimo aspecto de la descripción se proporciona un medio de almacenamiento legible por ordenador. El medio de almacenamiento legible por ordenador puede comprender instrucciones que, cuando son ejecutadas por al menos un procesador, hacen que el al menos un procesador realice el método de acuerdo con cualquiera de los anteriores aspectos primero y segundo.
Según un octavo aspecto de la descripción se proporciona una entidad UDM. La entidad UDM puede comprender un módulo de transmisión para transmitir una solicitud HTTP a la entidad UDR con el fin de mantener un contexto de espera de SMS para un dispositivo terminal, en la entidad UDR. El contexto de espera de SMS puede consistir en información relacionada con un reintento de una entrega de MT SMS desde al menos un SMS-SC al dispositivo terminal debido a un fallo en la entrega de MT SMS.
Según un noveno aspecto de la descripción se proporciona una entidad UDR. La entidad UDR puede comprender un módulo de mantenimiento para mantener, para un dispositivo terminal, un contexto de espera de SMS en respuesta a una solicitud HTTP procedente de una entidad UDM. El contexto de espera de SMS puede consistir en información relacionada con un reintento de una entrega de MT SMS desde al menos un SMS-SC al dispositivo terminal debido a un fallo en la entrega de MT SMS.
Según un décimo aspecto de la descripción se proporciona un sistema de comunicación. El sistema de comunicación puede comprender una entidad UDM y una entidad UDR. La entidad UDM puede estar configurada para transmitir una solicitud HTTP a la entidad UDR con el fin de mantener un contexto de espera de SMS en la entidad UDR para un dispositivo terminal. El contexto de espera de SMS puede consistir en información relacionada con un reintento de una entrega de MT SMS desde al menos un SMS-SC al dispositivo terminal debido a un fallo en la entrega de MT SMS. La entidad UDR puede estar configurada para mantener, para el dispositivo terminal, el contexto de espera de SMS en respuesta a la solicitud HTTP procedente de la entidad UDM.
Breve descripción de los dibujos
Estos y otros objetos, características y ventajas de la descripción se harán evidentes a partir de la siguiente descripción detallada de realizaciones ilustrativas de la misma, que deben leerse en relación con los dibujos adjuntos.
La Figura 1 es un diagrama que ilustra la arquitectura sin itinerancia para SMS a través de NAS;
la Figura 2 es un diagrama que ilustra la arquitectura sin itinerancia para SMS a través de NAS en representación de puntos de referencia;
la Figura 3 es un diagrama que ilustra la arquitectura de itinerancia para SMS a través de NAS;
la Figura 4 es un diagrama que ilustra la arquitectura de itinerancia para SMS a través de NAS en representación de puntos de referencia;
la Figura 5 es un diagrama que ilustra un sistema de comunicación ejemplar en el que se puede aplicar una realización de la descripción;
la Figura 6 es un diagrama de flujo que ilustra un método implementado en una entidad UDM de acuerdo con una realización de la descripción;
la Figura 7 es un diagrama de flujo para explicar el método de la Figura 6;
la Figura 8 es un diagrama de flujo para explicar el método de la Figura 6;
la Figura 9 es un diagrama de flujo que ilustra un método implementado en una entidad UDM de acuerdo con una realización de la descripción;
la Figura 10 es un diagrama de flujo que ilustra un método implementado en una entidad UDR de acuerdo con una realización de la descripción;
la Figura 11 es un diagrama de flujo que ilustra un método implementado en una entidad UDR de acuerdo con una realización de la descripción;
la Figura 12 es un diagrama de flujo que ilustra un proceso ejemplar de registro de UE con soporte de servicio SMS;
las Figuras 13A-13B son diagramas de flujo que ilustran un proceso ejemplar de acuerdo con una realización de la descripción;
las Figuras 14A-14B son diagramas de flujo que ilustran un proceso ejemplar de acuerdo con una realización de la descripción;
la Figura 15 es un diagrama que ilustra la estructura de los datos de suscripción de acuerdo con una realización de la descripción;
la Figura 16 es un diagrama de bloques que muestra un aparato adecuado para su uso en la práctica de algunas realizaciones de la descripción;
la Figura 17 es un diagrama de bloques que muestra una entidad UDM de acuerdo con una realización de la descripción; y
la Figura 18 es un diagrama de bloques que muestra una entidad UDR de acuerdo con una realización de la descripción.
Descripción detallada
Con fines explicativos, en la siguiente descripción se exponen detalles para proporcionar una comprensión completa de las realizaciones descritas. Sin embargo, para los expertos en la técnica es evidente que las realizaciones pueden implementarse sin estos detalles específicos o con una disposición equivalente.
Según la sección 4.13.3.9 de 3 GPP TS 23.502 V16.3.0, el procedimiento de reintento fallido de entrega de SMS con terminación en móvil se define como sigue. Si el UE está registrado a través tanto de acceso 3GPP como de acceso no 3GPP en la misma AMF (es decir, el UE está registrado en la misma PLMN para los dos tipos de acceso): si la entrega de MT-SMS a través de un Tipo de Acceso ha fallado, la AMF, sobre la base de la política local del operador, puede reintentar la entrega de MT-SMS a través del otro Tipo de Acceso antes de indicar el fallo a SMSF; y si la entrega de MT-SMS en los dos Tipos de Acceso ha fallado, la AMF informará a la SMSF inmediatamente.
Si la AMF informa a la SMSF de que no puede entregar el MT-SMS al UE, la SMSF envía un informe de fallo al primer SMS-GMSC (que puede estar situado junto con IP-SM-GW o rúter de SMS) como se define en TS 23.040. Si el SMS-GMSC tiene más de una entidad para el transporte de SMS hacia el UE, después de recibir el informe de fallo de MT-SMS, el SMS-GMSC, sobre la base de la política local del operador, puede reintentar la entrega de MT-SMS a través de la otra entidad.
Después de que el primer SMS-GMSC informe a la UDM/servidor de abonado doméstico (HSS, por sus siglas en inglés) de que el UE no puede recibir MT-SMS, la UDM establecerá su indicador URRP-AMF interno. Si el UE está registrado en una AMF y la UDM aún no se ha suscrito a la Notificación de Accesibilidad del UE en la AMF, la UDM inicia inmediatamente un procedimiento de suscripción como se especifica en la cláusula 4.2.5.2. Cuando la AMF detecta actividades de UE, notifica a la UDM con la Notificación de Actividad de UE como se describe en la cláusula 4.2.5.3. La UDM elimina su indicador URRP-AMF y alerta a los SC relacionados para que reintenten la entrega de MT-SMS.
Cuando el SMS-GMSC solicita información de enrutamiento desde la UDM para un UE no registrado en el núcleo de quinta generación (5GC, por sus siglas en inglés), o para un UE registrado que aún no ha sido registrado para el servicio de SMS, la UDM responde al SMS-GMSC que el UE está ausente, almacena la dirección SC en la lista MWD (si aún no está almacenada) y lo indica al SC como se define en TS 23.040. La UDM también establece un indicador de notificación de registro de SMSF interno para notificar al SC sobre el posterior registro de SMSF para el UE. Cuando la UDM recibe una Solicitud Nudm_UECM_Registration procedente de una SMSF para un UE para el que se ha establecido el indicador de notificación de registro de SMSF, la UDM elimina el indicador y alerta a los SC relacionados para que reintenten la entrega de MT-SMS. Téngase en cuenta que este escenario asume que el UE no está en cobertura 2G/3G/4G.
Con la introducción de la arquitectura basada en servicios (SBA, por sus siglas en inglés) de 5G en la red central basada en paquetes y el UDR como un repositorio de etapa final común, se podrían implementar funciones de red (NF, por sus siglas en inglés) como etapa inicial sin estado y sus estados necesarios y el contexto entre sesiones se almacenan en el UDR. El Modelo de Recursos UDR para la interfaz de programación de aplicaciones (API) Nudr se describe en la sección 5.2.1 de 3GPP TS 29.505 V16.1.0. La Figura 5.2.1-1 y la Figura 5.2.1-2 de esta especificación técnica muestran la estructura de subnivel del identificador uniforme de recursos (URI, por sus siglas en inglés) para los datos de suscripción. La Tabla 5.2.1-1 de esta especificación técnica proporciona una sinopsis de los recursos y los métodos HTTP aplicables.
Para soportar el reintento fallido de entrega de SMS de terminación móvil (MT-SMS), la UDM, por un lado, debe soportar el monitoreo de eventos de accesibilidad del UE si el motivo del fallo consiste en que el UE no está presente, o estar lista para la notificación si el motivo del fallo consiste en que se ha excedido la memoria en el lado del cliente. Por otro lado, cuando recibe una notificación de evento accesible de UE y evento de memoria disponible, la UDM debe alertar al SMS-SC para que reintente la entrega de MT-SMS que falló anteriormente. Dado que existe un cierto período de tiempo entre el momento en que la UDM sabe que la entrega del SMS ha fallado y el momento en que la UDM sabe que se puede volver a intentarlo, el contexto de espera de MT-SMS debe almacenarse para el acceso en algún lugar para UDM sin estado. Sin embargo, a partir de la última API de Nudr representada en la Figura 5.2.1-1 y la Figura 5.2.1-2 de 3GPP TS 29.505 V16.1.0, los datos de contexto de espera de SMS para servicio de SMS 5G no son soportados por el UDR. Por lo tanto, el reintento fallido de entrega de MT-SMS no funciona realmente en una implementación 5GC. Es aún peor cuando se trata de clientes verticales que aún no tienen desplegada una generación heredada de redes móviles.
La presente descripción propone una solución mejorada para la entrega de SMS. La solución se describirá en detalle a continuación con referencia a las Figuras 5-18.
La Figura 5 es un diagrama que muestra un sistema de comunicación ejemplar en el que se puede aplicar una realización de la descripción. Como se muestra, el sistema de comunicación comprende un UE, una red de acceso (por radio) ((R)AN, por sus siglas en inglés), una función de plano de usuario (UPF, por sus siglas en inglés), una red de datos (DN, por sus siglas en inglés), una función de gestión de movilidad y acceso (AMF, por sus siglas en inglés), una sesión función de gestión (SMF, por sus siglas en inglés), una función de control de políticas (PCF, por sus siglas en inglés), una función de aplicación (AF, por sus siglas en inglés), una función de servicio de mensajes cortos (SMSF, por sus siglas en inglés), una función de selección de segmento de red (NSSF, por sus siglas en inglés), una función de servidor de autentificación (AUSF, por sus siglas en inglés), una función de datos unificados (UDM, por sus siglas en inglés) y un repositorio de datos unificado (UDR, por sus siglas en inglés). La descripción funcional de las anteriores entidades se especifica en la cláusula 6 de 3GPP TS 23.501 V16.3.0.
Téngase en cuenta que el término UE utilizado en la presente memoria también puede designarse, por ejemplo, como dispositivo terminal, terminal de acceso, estación móvil, unidad móvil, estación de abonado, o similares. Puede referirse a cualquier dispositivo final que pueda acceder a una red de comunicación inalámbrica y recibir servicios de la misma. A modo de ejemplo y no de limitación, el UE puede incluir un ordenador portátil, un dispositivo terminal de captura de imágenes tal como una cámara digital, un dispositivo terminal de juegos, un aparato de almacenamiento y reproducción de música, un teléfono móvil, un teléfono celular, un teléfono inteligente, una tableta, un dispositivo ponible, un asistente digital personal (PDA, por sus siglas en inglés), o similares.
En un escenario de Internet de las cosas (IoT, por sus siglas en inglés), un UE puede representar una máquina u otro dispositivo que realiza monitoreo y/o mediciones, y transmite los resultados de dicho monitoreo y/o dichas mediciones a otro UE y/o a un equipo de red. En este caso, el UE puede ser un dispositivo de máquina a máquina (M2M), que, en un contexto de 3 GPP, puede designarse como dispositivo de comunicación de tipo máquina (MTc , por sus siglas en inglés). Los ejemplos particulares de dichas máquinas o dispositivos pueden incluir sensores, dispositivos de medición tales como medidores de potencia, maquinaria industrial, bicicletas, vehículos o electrodomésticos o aparatos personales, por ejemplo, refrigeradores, televisores, dispositivos ponibles como relojes, etc.
Como se usa en la presente memoria, la expresión "sistema de comunicación" se refiere a un sistema que sigue cualquier estándar de comunicación adecuado, como los protocolos de comunicación de primera generación (1G), 2G, 2,5G, 2,75G, 3G, 4G, 4,5G, 5G, y/o cualquier otro protocolo conocido actualmente o que se desarrolle en el futuro. Además, las comunicaciones entre un dispositivo terminal y un nodo de red en el sistema de comunicación se pueden realizar de acuerdo con cualquier protocolo de comunicación de generación adecuado, incluyendo, entre otros, protocolos de comunicación 1G, 2G, 2,5G, 2,75G, 3G, 4G, 4,5G, 5G, y/o cualquier otro protocolo conocido actualmente o que se desarrolle en el futuro. Además, los términos específicos utilizados en la presente memoria no limitan la presente descripción únicamente al sistema de comunicación relacionado con los términos específicos, que, no obstante, se pueden aplicar de forma más general a otros sistemas de comunicación.
La Figura 6 es un diagrama de flujo que ilustra un método implementado en una entidad UDM de acuerdo con una realización de la descripción. En el bloque 602, la entidad UDM mantiene un contexto de espera de SMS para un dispositivo terminal. El contexto de espera de SMS consiste en información relacionada con un reintento de una entrega de MT SMS desde al menos un SMS-SC al dispositivo terminal debido a un fallo en la entrega de MT SMS. De este modo, cuando se puede iniciar el reintento de entrega de MT SMS, éste puede ser activado por la entidad UDM, ya que se mantiene el contexto de espera de SMS.
Por ejemplo, el contexto de espera de SMS para el dispositivo terminal puede incluir, pero sin limitarse a, al menos uno de: una lista de una dirección del al menos un SMS-SC; una lista de un tiempo de caducidad del al menos un SMS-SC hasta el cual es válido el reintento de la entrega del MT SMS por parte del al menos un SMS-SC; un primer indicador que indica que un motivo para el fallo de la entrega de MT SMS consiste en que el dispositivo terminal no está accesible; un segundo indicador que indica que el motivo del fallo de la entrega de MT SMS consiste en que se ha excedido la capacidad de memoria del dispositivo terminal; un tercer indicador que indica un motivo para el reintento de la entrega del MT SMS; un primer punto en el tiempo hasta el cual es válido el reintento de la entrega del MT SMS; y un segundo punto en el tiempo hasta el cual es válido el segundo indicador. El tercer indicador puede tener un primer valor que indique que el dispositivo terminal está accesible para el reintento y/o un segundo valor que indique que el dispositivo terminal tiene memoria disponible para el reintento.
Como opción, el contexto de espera de SMS se puede mantener en una entidad UDR en respuesta a una solicitud procedente de la entidad UDM. Por ejemplo, el contexto de espera de SMS puede mantenerse interactuando con la entidad UDR a través de al menos una de las siguientes acciones: consultar a la entidad UDR sobre un contexto de espera de SMS para el dispositivo terminal; crear un contexto de espera de SMS para el dispositivo terminal; y actualizar el contexto de espera de SMS para el dispositivo terminal. Como ejemplo ilustrativo, la consulta se puede realizar enviando una solicitud HTTP GET a la entidad UDR. La creación se puede realizar enviando una solicitud HTTP PUT a la entidad UDR. La actualización se puede realizar enviando una solicitud HTTP PUT o PATCH a la entidad UDR. Como otra opción, también es posible que la entidad UDM tenga un componente de almacenamiento con una función similar a la entidad UDR de tal modo que el contexto de espera SMS se mantenga dentro de la propia entidad UDM.
Por ejemplo, el mantenimiento en el bloque 602 se puede realizar en respuesta a que la entidad UDM sea informada sobre un fallo en la entrega de MT SMS, o en respuesta a un evento que indique que se puede iniciar el reintento. Dependiendo de diferentes condiciones, el bloque 602 puede implementarse como bloques 708 y 710, o bloques 708 y 712, o bloques 814 y 816. En el bloque 708, en respuesta a la recepción de información sobre un fallo en la entrega de MT SMS, la entidad UDM consulta a la entidad UDR sobre un contexto de espera de SMS para el dispositivo terminal. Como primer ejemplo, se puede informar a la entidad UDM de que el motivo del fallo de la entrega del MT SMS consiste en que no se puede acceder al dispositivo terminal. Como segundo ejemplo, se puede informar a la entidad UDM de que el motivo del fallo de la entrega del MT SMS consiste en que se ha excedido la capacidad de memoria del dispositivo terminal.
Si no ha habido un contexto de espera de SMS almacenado en la entidad UDR para el dispositivo terminal, la entidad UDM crea un contexto de espera de SMS en la entidad UDR para el dispositivo terminal en el bloque 710. Por otro lado, si ha habido un contexto de espera de SMS almacenado en la entidad UDR para el dispositivo terminal y el fallo de la entrega de MT SMS está relacionado con un SMS-SC diferente al del contexto de espera de SMS, la entidad UDM actualiza el contexto de espera de SMS en la entidad UDR para el dispositivo terminal en el bloque 712. En relación con el anterior primer ejemplo, el contexto de espera de SMS creado o actualizado puede incluir el primer indicador. En relación con el anterior segundo ejemplo, el contexto de espera de SMS creado o actualizado puede contener el segundo indicador.
En el bloque 814, en respuesta a un evento que indica que se puede iniciar el reintento, la entidad UDM consulta a la entidad UDR sobre el contexto de espera de SMS para el dispositivo terminal. Como tercer ejemplo, el evento puede consistir en que se informe a la entidad UDM de que se puede acceder al dispositivo terminal. Como cuarto ejemplo, el evento puede consistir en que se informe a la entidad UDM de que el dispositivo terminal tiene memoria disponible para el reintento. En el bloque 816, la entidad UDM actualiza el contexto de espera de SMS en la entidad UDR para el dispositivo terminal. En relación con el anterior tercer ejemplo, es posible que el contexto de espera de SMS consultado incluya el primer indicador y no incluya el segundo indicador. En este caso, el contexto de espera de SMS puede actualizarse en la entidad UDR eliminando el primer indicador del contexto de espera de SMS. Obsérvese que el término “eliminar” se puede referir al primer indicador ajustado a un valor opuesto cuando el primer indicador puede tener dos valores opuestos (por ejemplo, TRUE y FALSE para indicar condiciones opuestas.
En relación con el anterior cuarto ejemplo, es posible que el contexto de espera de SMS consultado incluya el segundo indicador y no incluya el primer indicador. En este caso, el contexto de espera de SMS puede actualizarse en la entidad UDR eliminando el segundo indicador del contexto de espera de SMS. En relación con los anteriores ejemplos tercero y cuarto, también es posible que el contexto de espera de SMS consultado no incluya el primer indicador ni el segundo indicador. En este caso, el contexto de espera de SMS puede actualizarse en la entidad UDR agregando el tercer indicador y el primer punto en el tiempo en el contexto de espera de SMS. El tercer indicador puede tener el primer valor (que indica que el dispositivo terminal está accesible para el reintento) para el tercer ejemplo, y el segundo valor (que indica que el dispositivo terminal tiene memoria disponible para el reintento) para el cuarto ejemplo.
La Figura 9 es un diagrama de flujo que ilustra un método implementado en una entidad UDM de acuerdo con una realización de la descripción. Como se muestra, el método comprende los bloques 602, 904 y 906. Téngase en cuenta que el bloque de línea discontinua puede ser un bloque opcional. El bloque 602 se ha descrito más arriba y sus detalles se omiten aquí. En el bloque 904, la entidad UDM alerta al, al menos un, SMS-SC de que se puede iniciar el reintento de la entrega de MT SMS para el dispositivo terminal, sobre la base del contexto de espera de SMS mantenido. Por ejemplo, el bloque 904 se puede realizar en respuesta a que se informe a la entidad UDM de que se puede acceder al dispositivo terminal o que el dispositivo terminal tiene memoria disponible para el reintento. Al menos la lista de la dirección del al menos un SMS-SC puede usarse para alertar al, al menos un, SMS-SC. Con el método que comprende los bloques 602 y 904, el reintento de la entrega de SMS puede estar soportado por la entidad UDM.
Opcionalmente, en el bloque 906, la entidad UDM elimina el contexto de espera de SMS mantenido después de alertar al, al menos un, SMS-SC. En caso de que el contexto de espera de SMS se mantenga en la entidad UDR, el contexto de espera de SMS mantenido puede eliminarse de la entidad UDR. Como ejemplo ilustrativo, la eliminación se puede realizar enviando una solicitud HTTP DELETE a la entidad UDR. En caso de que el contexto de espera de SMS se mantenga dentro de la propia entidad UDM, la entidad UDM puede simplemente eliminar el contexto de espera de SMS.
La Figura 10 es un diagrama de flujo que ilustra un método implementado en una entidad UDR de acuerdo con una realización de la descripción. En el bloque 1002, la entidad UDR mantiene, para un dispositivo terminal, un contexto de espera de SMS en respuesta a una solicitud procedente de una entidad UDM. El contexto de espera de SMS consiste en información relacionada con un reintento de una entrega de MT SMS desde al menos un SMS-SC al dispositivo terminal debido a un fallo en la entrega de MT SMS. Con el método de la Figura 10, es posible que la entidad UDM active el reintento de la entrega de MT SMS ya que se mantiene el contexto de espera de SMS.
Los detalles del contexto de espera de SMS se han descrito más arriba y, por lo tanto, se omiten aquí. El contexto de espera de SMS se puede mantener mediante al menos una de las siguientes acciones: responder a una consulta procedente de la entidad UDM sobre un contexto de espera de SMS para el dispositivo terminal; crear un contexto de espera de SMS para el dispositivo terminal; y actualizar el contexto de espera de SMS para el dispositivo terminal. Como ejemplo ilustrativo, la consulta puede ser una solicitud HTTP GET. La creación se puede realizar recibiendo una solicitud HTTP PUT procedente de la entidad UDM. La actualización se puede realizar recibiendo una solicitud HTTP PUT o PATCH procedente de la entidad UDM.
La Figura 11 es un diagrama de flujo que ilustra un método implementado en una entidad UDR de acuerdo con una realización de la descripción. Como se muestra, el método comprende los bloques 1002 y 1104. En el bloque 1104, la entidad UDR elimina el contexto de espera de SMS mantenido en respuesta a otra solicitud procedente de la entidad UDM. Como ejemplo ilustrativo, la eliminación se puede realizar recibiendo una solicitud HTTP DELETE procedente de la entidad UDM.
Sobre la base de lo anterior, al menos un aspecto de la descripción proporciona un método implementado en un sistema de comunicación que incluye una entidad UDM y una entidad UDR. El método comprende mantener, por parte de la entidad UDM, un contexto de espera de SMS en la entidad UDR para un dispositivo terminal. El contexto de espera de SMS consiste en información relacionada con un reintento de una entrega de MT SMS desde al menos un SMS-SC al dispositivo terminal debido a un fallo en la entrega de MT SMS. La entidad UDR mantiene, para el dispositivo terminal, el contexto de espera de SMS en respuesta a una solicitud procedente de la entidad UDM.
En consecuencia, al menos un aspecto de la descripción proporciona un sistema de comunicación que comprende una entidad UDM y una entidad UDR. La entidad UDM está configurada para mantener un contexto de espera de SMS en la entidad UDR para un dispositivo terminal. El contexto de espera de SMS consiste en información relacionada con un reintento de una entrega de MT SMS desde al menos un SMS-SC al dispositivo terminal debido a un fallo en la entrega de MT SMS. La entidad UDR está configurada para mantener, para el dispositivo terminal, el contexto de espera de SMS en respuesta a una solicitud procedente de la entidad UDM.
Para una mejor comprensión de la descripción se describirá, con referencia a la Figura 12, un proceso de registro de UE en una red central 5G con servicio de SMS soportado. Como se muestra, este proceso implica un UE, una red de acceso (AN, por sus siglas en inglés), una AMF, una SMSF, una UDM y un UDR. Una vez que el registro del UE tiene éxito, hay un contexto de registro almacenado en el UDR que podría ser consultado si hay un MT-SMS pendiente de entrega al UE, como se representa en la etapa 3 de la Figura 13A y la Figura 14A.
En la etapa 1, durante el procedimiento de registro del UE 5G, para posibilitar el transporte de SMS a través de NAS, el UE incluye una indicación "SMS soportado" en la Solicitud de Registro que indica la capacidad del UE para el transporte de SMS a través de NAS. La indicación "SMS soportado" indica si el UE soporta la entrega de SMS a través de n As . En la etapa 2, la AMF descubre una UDM para el registro de AMF. En las etapas 3 a 5, la AMF se registra en la UDM para acceso 3GPP o para acceso no 3GPP. El contexto de registro también se almacena en el UDR. En la etapa 6, si se incluye la indicación "SMS soportado" en la Solicitud de Registro, la AMF verifica los datos de suscripción de SMS de la UDM para el UE sobre si el servicio de SMS está suscrito por el UE. En la etapa 7, la AMF se suscribe a la notificación de cambio de datos para los datos de suscripción de SMS.
En la etapa 8, si el servicio de SMS está suscrito y el contexto del UE no incluye una SMSF disponible de la PLMN de servicio, la AMF descubre y selecciona una SMSF para dar servicio al UE. En la etapa 9, la AMF invoca la operación de servicio Nsmsf_SMService_Activate desde la SMSF. La invocación incluye la dirección AMF, el Tipo de Acceso, el tipo de tecnología de acceso por radio (RAT, por sus siglas en inglés), los requisitos de Rastreo, el identificador de suscripción pública genérica (GPSI, por sus siglas en inglés) (si está disponible) y el identificador permanente de suscripción (SUPI, por sus siglas en inglés). La AMF usa la dirección SMSF derivada de la etapa 8.
En la etapa 10, la SMSF descubre una UDM para el registro de SMSF. Si el contexto de UE ya existe en la SMSF, la SMSF reemplazará la antigua dirección AMF con la nueva dirección AMF. De lo contrario, en la etapa 11, la SMSF se registra con la UDM utilizando Nudm_UECM_Registration con Tipo de Acceso (3GPP/no 3GPP). En la etapa 12, la UDM almacena el contexto de registro de SMSF en el UDR. En la etapa 13, la UDM responde a la SMSF para la solicitud de registro de SMSF. En la etapa 14, la SMSF recupera los datos de suscripción de gestión de SMS utilizando Nudm_SDM_Get (la UDM puede obtener esta información desde el UDR mediante Nudr_DR_Query) y la SMSF también crea un contexto de UE para almacenar la información de suscripción de gestión de SMS y la dirección AMF que da servicio a este UE. En la etapa 15, la SMSF se suscribe para ser notificada cuando se modifiquen los datos de suscripción de gestión de SMS (la UDM se puede suscribir a notificaciones procedentes del UDR mediante Nudr_DR_Subscribe).
En la etapa 16, la SMSF responde a la AMF con el mensaje de respuesta de operación de servicio Nsmsf_SMService_Activate. La AMF almacena la dirección SMSF recibida como parte del contexto de UE. En la etapa 17, la AMF incluye la indicación "SMS permitido" al UE en el mensaje de Aceptación de Registro si la AMF ha recibido una indicación positiva de la SMSF seleccionada. La indicación "SMS permitido" en el mensaje de Aceptación de Registro indica al UE si la red permite la entrega de mensajes SMS a través de NAS.
Las Figuras 13A-13B ilustran un proceso ejemplar de acuerdo con una realización de la descripción. Corresponde a un caso de uso para el reintento de MT-SMS después de un fallo de suscriptor ausente. Como se muestra, el proceso implica un UE, una AN, una AMF, una SMSF, una UDM, un UDR, un SMS-IWMSC, un SMS-GMSC y un SMS-SC. En la etapa 1, el SMS-SC tiene un SMS pendiente de envío a un UE de destino, por lo que envía el mensaje a una entidad SMS SMS-GMSC. En la etapa 2, el SMS-GMSC consulta al nodo de servicio de SMS actual sobre el UE de destino (la identidad del mismo podría ser MSISDN o IMSI) desde la UDM. En el dominio 5G, el nodo SMS de servicio es una SMSF. El procedimiento de registro de UE en 5G se ha descrito más arriba con referencia a la Figura 12. En la etapa 3, la UDM consulta al nodo de servicio de SMS actual sobre el UE de destino desde el UDR. Supóngase que el UE se ha registrado antes en el dominio 5G. Entonces, la UDR devuelve una dirección SMSF. En la etapa 4, la UDM responde a la entidad SMS SMS-GMSC de la dirección SMSF de servicio para el UE de destino. En la etapa 5, el SMS-GMSC envía el MT-SMS a la dirección de SMSF obtenida en la etapa 4.
En la etapa 6, la SMSF ejecuta el procedimiento de entrega de MT-SMS a través de NAS, que además puede activar la búsqueda del UE si el UE no está en estado conectado. La entrega puede tener éxito o fallar según el estado de conectividad del UE en la red o el estado de la memoria en el UE. En este proceso, supóngase que la entrega de SMS falla porque el UE está ausente en la red. Entonces, en la etapa 7, la SMSF envía un informe de entrega de MT-SMS al SMS-GSMC y al SMS-SC. El indicador de fallo indica un motivo de fallo de Suscriptor Ausente. En la etapa 8, el SMS-GMSC notifica el estado de entrega del MT-SMS a la UDM. El motivo del fallo incluido en el mensaje es Suscriptor Ausente. En la etapa 9, la UDM verifica el motivo del fallo y luego, en función del fallo de suscriptor ausente, inicia la Gestión de Fallo de Suscriptor Ausente.
En la etapa 10, la UDM consulta al UDR si existe un contexto de espera de SMS para el UE de destino. Dado que esto no está soportado por el UDR en la técnica anterior, este mensaje se basa en nuestro nuevo método GET propuesto. Si antes no existía ningún contexto de espera de SMS, la UDM crea y almacena el contexto de espera de SMS para el UE en el UDR en la etapa 11. Dado que esto no está soportado por el UDR en la técnica anterior, este mensaje se basa en nuestro nuevo método PUT propuesto. En el cuerpo del mensaje, un indicador móvil no accesible (MNRF, por sus siglas en inglés) se establece en verdadero para indicar el motivo del fallo de Suscriptor Ausente. Por otro lado, si existe un contexto de espera de SMS anterior para el mismo motivo de fallo, la UDM verifica si se trata de una nueva dirección de SMS-SC. Si esto es un fallo para una nueva dirección SMS-SC, el UDM actualiza después el contexto de espera de SMS para el UE de destino en la etapa 12 agregando la nueva dirección de SMS-SC. Dado que esto no está soportado por el UDR en la técnica anterior, este mensaje se basa en nuestro nuevo método PATCH propuesto para actualización delta o en nuestro nuevo método PUT propuesto para actualización completa. En la etapa 13, la UDM responde al SMS-GMSC para la solicitud de estado de entrega de SM del informe en la etapa 8.
Si la accesibilidad del UE para el evento de SMS no se ha suscrito antes, la UDM suscribe la accesibilidad del UE para el evento de SMS desde la AMF en función de sus interfaces expuestas Namf_EventExposure_Subscribe en la etapa 14. Algún tiempo después, el UE vuelve a estar accesible para SMS en la etapa 15, por ejemplo dentro de un área de buena cobertura. En la etapa 16, una vez que detecta que el UE es accesible para SMS, la AMF notifica a la UDM este evento accesible para SMS mediante Namf_EventExposure_Notify.
En la etapa 17, la UDM consulta al UDR el contexto de espera de SMS del UE de destino. Dado que esto no está soportado por el UDR en la técnica anterior, este mensaje se basa en nuestro nuevo método GET propuesto. Si el MNRF es verdadero y el indicador de superación de capacidad de memoria (MCEF, por sus siglas en inglés) es falso, la UDM actualiza el contexto de espera de SMS almacenado en el UDR para establecer el indicador MNRF en falso en la etapa 18. Dado que esto no está soportado por el UDR en la técnica anterior, este mensaje se basa en nuestro nuevo método PATCH propuesto para actualización delta o se basa en nuestro nuevo método PUT propuesto para actualización completa. Para cada dirección de SMS-SC almacenada en el contexto de espera de SMS, la UDM envía el mensaje del centro de servicio de alerta al SMS-SC a través del SMS-IWMSC en la etapa 19, con un motivo de alerta para indicar un reintento de entrega de SMS deseado debido a presencia de MS. Una vez recibido el mensaje de alerta, el SMS-SC podría activar el procedimiento de reenvío de SMS. Si se han enviado todos los mensajes del centro de servicios de alerta, la UDM elimina el contexto de espera de mensajes para el UE de destino del UDR en la etapa 20. Dado que esto no está soportado por el UDR en la técnica anterior, este mensaje se basa en nuestro nuevo método DELETE propuesto.
Si el MNRF es falso y el MCEF es falso, la UDM actualiza el contexto de espera de SMS almacenado en el UDR en la etapa 21. La actualización se basa en el motivo del reintento como MS presente y el tiempo válido para el reintento. Dado que esto no está soportado por el UDR en la técnica anterior, este mensaje se basa en nuestro nuevo método PATCH propuesto para actualización delta o se basa en nuestro nuevo método PUT propuesto para actualización completa.
Las Figuras 14A-14B ilustran un proceso ejemplar de acuerdo con una realización de la descripción. Corresponde a un caso de uso para reintento de MT-SMS después de un fallo de memoria excedida. De modo similar a las Figuras 13A-13B, el proceso implica un UE, una AN, una AMF, una SMSF, una UDM, un UDR, un SMS-IWMSC, un SMS-GMSC y un SMS-SC. En la etapa 1, el SMS-SC tiene SMS pendientes de enviar a un UE de destino, por lo que envía el mensaje a una entidad de SMS SMS-GMSC. En la etapa 2, el SMS-GMSC consulta al nodo de servicio de SMS actual sobre el UE de destino (la identidad del mismo podría ser MSISDN o IMSI) desde la UDM. En el dominio 5G, el nodo SMS de servicio es una SMSF. El procedimiento de registro de UE en 5G se ha descrito más arriba con referencia a la Figura 12. En la etapa 3, la UDM consulta al nodo de servicio de SMS actual sobre el UE de destino desde el UDR. Supóngase que el UE se ha registrado antes en el dominio 5G. Entonces, el UDR devuelve una dirección SMSF. En la etapa 4, la u Dm responde a la entidad SMS SMS-GMSC de la dirección SMSF de servicio para el UE de destino. En la etapa 5, el SMS-GMSC envía el MT-SMS a la dirección de SMSF obtenida en la etapa 4.
En la etapa 6, la SMSF ejecuta el procedimiento de entrega de MT-SMS a través de NAS, lo que además puede activar la búsqueda del UE si el UE no está en estado conectado. La entrega puede tener éxito o fallar según el estado de conectividad del UE en la red o el estado de la memoria en el UE. En este proceso, supóngase que la entrega de SMS falla debido a que se ha excedido la capacidad de memoria del UE. Después, en la etapa 7, la SMSF envía un informe de entrega de MT-SMS al SMS-GSMC y al SMS-SC. El indicador de fallo indica un motivo de fallo de Memoria Excedida. En la etapa 8, el SMS-GMSC notifica el estado de entrega del MT-SMS a la UDM. El motivo del fallo incluido en el mensaje consiste en Memoria Excedida. En la etapa 9, la UDM verifica el motivo del fallo y después, en función del fallo de Memoria Excedida, inicia la Gestión de Fallo de Memoria Excedida.
En la etapa 10, la UDM consulta al UDR si hay un contexto de espera de SMS existente para el UE de destino. Dado que esto no está soportado por el UDR en la técnica anterior, este mensaje se basa en nuestro nuevo método GET propuesto. Si antes no existía ningún contexto de espera de SMS, la UDM crea y almacena el contexto de espera de SMS para el UE en el UDR en la etapa 11. Dado que esto no está soportado por el UDR en la técnica anterior, este mensaje se basa en nuestro nuevo método PUT propuesto. En el cuerpo del mensaje, un indicador de memoria excedida (MCEF) móvil se establece en verdadero para indicar el motivo del fallo de Memoria Excedida. Por otro lado, si existe un contexto de espera de SMS anterior por el mismo motivo de fallo, la UDM verifica si se trata de una nueva dirección de SMS-SC. Si esto es un fallo para una nueva dirección SMS-SC, la UDM actualiza el contexto de espera de SMS para el UE de destino en la etapa 12 agregando la nueva dirección de SMS-SC. Dado que esto no está soportado por el UDR en la técnica anterior, este mensaje se basa en nuestro nuevo método PATCH propuesto para actualización delta o se basa en nuestro nuevo método PUT propuesto para actualización completa. En la etapa 13, la UDM responde al SMS-GMSC para la solicitud de estado de entrega del informe SM en la etapa 8.
Algún tiempo después, la memoria del UE vuelve a estar disponible para SMS en la etapa 14, por ejemplo, se libera más memoria en el UE, y el UE informa de este estado a la red. En la etapa 15, la UDM consulta al UDR el contexto de espera de SMS del UE de destino. Dado que esto no está soportado por el UDR en la técnica anterior, este mensaje se basa en nuestro nuevo método GET propuesto. Si el MCEF es verdadero y el MNRF es falso, la UDM actualiza el contexto de espera de SMS almacenado en el UDR para establecer el indicador MCEF en falso en la etapa 16. Dado que esto no está soportado por el UDR en la técnica anterior, este mensaje se basa en nuestro nuevo método PATCH propuesto para actualización delta o se basa en nuestro nuevo método PUT propuesto para actualización completa. Para cada dirección de SMS-SC almacenada en el contexto de espera de SMS, la UDM envía el mensaje del centro de servicio de alerta al SMS-SC a través del SMS-IWMSC, con un motivo de alerta para indicar un reintento deseado debido a la memoria disponible del UE. Una vez recibido el mensaje de alerta, el SMS-SC podría activar el procedimiento de reenvío de SMS. Si se han enviado todos los mensajes del centro de servicio de alerta, la UDM elimina los datos de mensaje en espera para el UE de destino desde el UDR en la etapa 18. Dado que esto no está soportado por el UDR en la técnica anterior, este mensaje se basa en nuestro nuevo método DELETE propuesto.
Si el MCEF es falso y el MNRF es falso, la UDM actualiza el contexto de espera de SMS almacenado en el UDR en la etapa 19. La actualización se basa en el motivo del reintento tal como la memoria disponible y el tiempo válido para el reintento. Dado que esto no está soportado por el UDR en la técnica anterior, este mensaje se basa en nuestro nuevo método PATCH propuesto para actualización delta o en nuestro nuevo método PUT propuesto para actualización completa.
De acuerdo con los procesos ejemplares anteriores, para resolver el problema de la técnica anterior consistente en que el UDR no soporta datos de contexto de espera de SMS para casos de uso de reintento de servicio SMS 5G, se introduce un método novedoso entre la UDM y el UDR para administrar el contexto de espera de SMS para el reintento. Por lo tanto, con la ayuda del nuevo método, el reintento fallido de entrega de MT-SMS podría ser realmente soportado en una implementación 5GC.
Sobre la base de la descripción anterior se propone realizar los siguientes cambios a las especificaciones técnicas actuales. En primer lugar se propone una nueva interfaz UDR y los recursos correspondientes para la gestión del contexto de espera de MT-SMS para el reintento. La Figura 15 muestra esta propuesta para la nueva interfaz UDR para el contexto de espera MT-SMS. Como se muestra, la estructura de subnivel de URI de recurso para datos de suscripción se actualiza con "/sms-waiting" en "/context-data", en comparación con la Figura 5.2.1-1 de 3GPP TS 29.505 V16.1.0. Esta actualización está resaltada por un cuadro dibujado con líneas gruesas.
La siguiente Tabla 1 muestra la propuesta de Sinopsis de recursos y métodos de UDR. Las actualizaciones están subrayadas en comparación con la Tabla 5.2.1-1 de 3GPP TS 29.505 V16.1.0.
Tabla 1: Sinopsis de recursos y métodos
(agregado con el recurso SmsWaitingContext en comparación con la Tabla 5.2.1-1 de 3GPP TS 29.505 V16.1.0)
Figure imgf000012_0001
Figure imgf000013_0001
Figure imgf000014_0001
Figure imgf000015_0001
Figure imgf000016_0001
Figure imgf000017_0001
Figure imgf000018_0001
En segundo lugar se proponen cuatro nuevas operaciones de servicio para la gestión del contexto de espera de MT-SMS para reintento: PUT: Crear/Actualizar un contexto de espera de MT-SMS individual para reintento; DELETE: Eliminar un contexto de espera de MT-SMS individual para reintento; PATCH: Actualizar un contexto de espera de MT-SMS individual para reintento; GET: Recuperar un contexto de espera de MT-SMS individual para reintento. Con la nueva interfaz Nudr y las operaciones de servicio relacionadas introducidas, los datos de contexto de espera de SMS para el reintento de SMS 5G pueden ser soportados por el UDR. Por lo tanto, una UDM sin estado podría funcionar como NF de etapa inicial y la UDR podría funcionar como el repositorio común de etapa final para soportar el servicio SMS 5G a través de NAS, especialmente para los casos de uso de reintento. El reintento fallido de entrega de MT-SMS puede ser soportado en una implementación 5GC, en una implementación privada para los clientes verticales que aún no tienen implementada una generación heredada de redes móviles.
Lo siguiente (5.2.X) es una propuesta de solicitud de cambio (CR, por sus siglas en inglés) para la descripción del recurso SmsWaitingContext y las cuatro operaciones de servicio correspondientes, en comparación con el último 3GPP TS 29.505 16.1.0 (12-2019). Todos los contenidos son secciones nuevas. La expresión "5.2.X" significa que, una vez aceptado por 3GPP, este subcapítulo está bajo 5.2, pero X debe decidirse cuando se publique.
5.2. X Recurso: SmsWaitingContext
5.2. X.1 Descripción
Este recurso representa los datos de espera de MT-SMS dinámicos para un UE. Éstos son creados, eliminados, actualizados o consultados por la UDM durante los procedimientos de entrega de MT-SMS (véase la cláusula 4.13.3.9 de 3GPP TS 23.502 [18]).
Este recurso está modelado con el arquetipo de recurso Documento (véase la cláusula C.1 de 3GPP TS 29.501 [7]).
5.2. X.2 Definición de recursos
URI de recurso: {apiRoot}/nudr-dr/<apiVersion>/subscription-data/{ueId}/context-data/sms-waiting
Este recurso soportará las variables URI de recurso definidas en la tabla 5.2.X.2-1.
Tabla 5.2.X.2-1: Variables de URI de recurso para este recurso
Figure imgf000018_0002
5.2. X.3 Métodos estándar de recursos
5.2. X.3.1 PUT
Este método soportará los parámetros de consulta de URI especificados en la tabla 5.2.X.3.1-1.
Tabla 5.2.X.3.1-1: Parámetros de consulta de URI soportados por el método GET en este recurso
Figure imgf000019_0001
Este método soportará las estructuras de datos de solicitud especificadas en la tabla 5.2.13.3.1-2 y las estructuras de datos de respuesta y los códigos de respuesta especificados en la tabla 5.2.13.3.1-3.
Tabla 5.2.X.3.1-2: Estructuras de datos soportadas por el Cuerpo de Solicitud PUT en este recurso
Figure imgf000019_0002
Tabla 5.2.X.3.1-3: Estructuras de datos soportadas por el Cuerpo de Respuesta PUT en este recurso
Figure imgf000019_0003
5.2.X.3.2 DELETE
Este método deberá soportar los parámetros de consulta de URI especificados en la tabla 5.2.X.3.2-1.
Tabla 5.2.X.3.2-1: Parámetros de consulta de URI soportados por el método DELETE en este recurso
Figure imgf000019_0004
Este método soportará las estructuras de datos de solicitud especificadas en la tabla 5.2.X.3.2-2 y las estructuras de datos de respuesta y los códigos de respuesta especificados en la tabla 5.2.X.3.2-3.
Tabla 5.2.X.3.2-2: Estructuras de datos soportadas por el Cuerpo de Solicitud DELETE en este recurso
Figure imgf000019_0005
Tabla 5.2.X.3.2-3: Estructuras de datos soportadas por el Cuerpo de Respuesta DELETE en este recurso
Figure imgf000019_0006
5.2.X.3.3 PATCH
Este método se utiliza para modificar los datos de parámetros proporcionados en el UDR.
Este método deberá soportar los parámetros de consulta de URI especificados en la tabla 5.2.X.3.3-1.
Tabla 5.2.X.3.3-1: Parámetros de consulta de URI soportados por el método PATCH en este recurso
Figure imgf000020_0001
Este método soportará las estructuras de datos de solicitud especificadas en la tabla 5.2.X.3.3-2 y las estructuras de datos de respuesta y los códigos de respuesta especificados en la tabla 5.2.X.3.3-3.
Tabla 5.2.X.3.3-2: Estructuras de datos soportadas por el Cuerpo de Solicitud PATCH en este recurso
Figure imgf000020_0002
Tabla 5.2.X.3.3-3: Estructuras de datos soportadas por el Cuerpo de Respuesta PATCH en este recurso
Figure imgf000020_0003
5.2.X.3.4 GET
Este método deberá soportar los parámetros de consulta de URI especificados en la tabla 5.2.X.3.4-1.
Tabla 5.2.X.3.4-1: Parámetros de consulta de URI soportados por el método GET en este recurso
Figure imgf000020_0004
Este método deberá soportar las estructuras de datos de solicitud especificadas en la tabla 5.2.X.3.4-2 y las estructuras de datos de respuesta y los códigos de respuesta especificados en la tabla 5.2.X.3.4-3.
Tabla 5.2.X.3.4-2: Estructuras de datos soportadas por el Cuerpo de Solicitud GET en este recurso
Figure imgf000020_0005
Tabla 5.2.X.3.4-3: Estructuras de datos soportadas por el Cuerpo de Respuesta GET en este recurso
Figure imgf000021_0001
El modelo de datos propuesto por la CR es el siguiente:
5.4.2.X Tipo: SmsWaitingContext
Tabla 5.4.2.X-1: SmsWaitingContext
Figure imgf000021_0002
5.4.2.Y Tipo: SmsScAddress
Tabla 5.4.2.Y-1: SmsScAddress
Figure imgf000021_0003
5.4.3.X Enumeración: MtsmsReattemptReason
Tabla 5.4.3.X-1: Enumeración MtsmsReattemptReason
Figure imgf000021_0004
Como 5G se basa en la arquitectura basada en servicios (SBA) y la interfaz utilizada entre las funciones de red (NF) se basa en una interfaz basada en servicios (SBI, por sus siglas en inglés), la interfaz se modela como API abierta y se define en archivos yaml. Lo siguiente es nuestra propuesta de CR para las actualizaciones delta de la API abierta de Nudr-Dr:
/subscription-data/(ueld)/context-data/sms-waiting:
put:
summary: Create/Update an individual MT-SMS waiting context for re-attempt operationld: CreateSmsWaitingContext
tags:
- SMS Waiting Context (Document)
parameters:
- ñame: ueld
in: path
description: UE id
required: true
schema:
$ref: 'TS29571_CommonData.yaml#/components/schemas/VarUeId, requestBody:
content:
application/json:
schema:
Sref: '#/components/schemas/SrasWaitingContext’
responsos:
•201' :
description: Expected response to a valid request
content:
application/json:
schema:
$ref: ’1/components/schemas/SmsWaitingContext'
default:
description: Unexpected error
content:
application/problem+json:
sch
Se
rm
ea
f:
: 'TS29571_CommonData.yaml#/components/schemas/ProblemDetails1 delete:
summary: Delete an individual MT-SMS waiting context for re-attempt operationld: DeleteSmsWaitingContext
tags:
- SMS Waiting Context (Document)
parameters:
- ñame: ueld
in: path
description: UE id
required: true
schema:
Sref: 'TS29571_CommonData.yamllt/components/schemas/VarUeld' responses:
'204':
description: Upon success, an empty response body shall be returned default:
description: unexpected error
content:
application/problem+json:
sc
Sh
re
em
fa
::
’TS29571_CoranonData.yamlf/components/schemas/ProblemDetails' patch:
sumnary: Update an individual MT-SMS waiting context for re-attempt operationld: UpdatesmswaitingContext
tags:
- SMS Waiting Context (Document)
parameters:
- ñame: ueld
in: path
description: pp data for a UE
required: true
schema:
Sref: 'TS29571_CommonData.yaml#/coraponents/schemas/VarUeId'
- name: supported-features
in: query
description: Features required to be supported by the target NF
sch
Se
rr
ea
fa
::
'TS29571_CommonData.yamHt/camponents/schemas/SupportedFeatures'
requestBody:
content:
application/json-patch+json:
schema:
type: array
Íte
Sm
rs
e:
f: 'TS29571_CommonData.yaml#/components/schemas/PatchItem'
required: true
responses:
•204':
description: Expected response to a valid request
'200':
description: Expected response to a valid request
content:
appiication/json:
scShreemfa:: 'TS29571_CommonData.yamHt/components/schemas/PatchResult'
'403':
description: modification is rejected
content:
application/problem+json:
sch
Se
rm
ea
f:
: 'TS29571 CommonData.yaml#/components/schemas/ProblemDetails1
default:
description: Unexpected error
content:
application/problem+json:
schSermeaf:: 'TS29571_CommonData.yamltl/components/schemas/ProblemDetails1
get:
suinmary: Retrieve an individual MT-SMS waiting context for re-attempt
operationld: QuerySmsWaitingContext
tags:
- SMS Waiting Context IDocument)
parameters:
- name: ueld
in: path
description: UE id
required: true
schema:
Sref: 'TS29571_CommonData.yamlt/components/achemas/VarUeld'
responses:
•200':
description: Expected response to a valid request
content:
application/json:
schema:
Sref: 'd/components/schemas/SmsWaitingContext'
default:
description: Unexpected error
content:
application/problem+json:
sch
Se
rm
ea
f:
: 'TS29571 CommonData.yamlfl/components/scheraas/ProblemDetails’
La Figura 16 es un diagrama de bloques que muestra un aparato adecuado para su uso en la práctica de algunas realizaciones de la descripción. Por ejemplo, cualquiera de las entidades UDM y UDR arriba descritas puede implementarse a través del aparato 1600. Como se muestra, el aparato 1600 puede incluir un procesador 1610, una memoria 1620 que almacena un programa y, opcionalmente, una interfaz 1630 de comunicación para comunicar datos con otros dispositivos externos a través de comunicación por cable y/o inalámbrica.
El programa incluye instrucciones de programa que, cuando son ejecutadas por el procesador 1610, permiten que el aparato 1600 funcione de acuerdo con las realizaciones de la presente descripción, como se ha discutido más arriba. Es decir, las realizaciones de la presente descripción pueden implementarse, al menos en parte, mediante software informático ejecutable por el procesador 1610, o mediante hardware, o mediante una combinación de software y hardware.
La memoria 1620 puede ser de cualquier tipo adecuado para el entorno técnico local y puede implementarse utilizando cualquier tecnología de almacenamiento de datos adecuada, como dispositivos de memoria basados en semiconductores, memorias flash, dispositivos y sistemas de memoria magnética, dispositivos y sistemas de memoria óptica, memorias fijas y memorias extraíbles. El procesador 1610 puede ser de cualquier tipo adecuado para el entorno técnico local y puede incluir uno o más ordenadores de uso general, ordenadores de uso especial, microprocesadores, procesadores de señales digitales (DSP, por sus siglas en inglés) y procesadores basados en arquitecturas de procesador de múltiples núcleos, como ejemplos no limitativos.
La Figura 17 es un diagrama de bloques que muestra una entidad UDM de acuerdo con una realización de la descripción. Como se muestra, la entidad UDM 1700 comprende un módulo 1702 de mantenimiento configurado para mantener un contexto de espera de SMS para un dispositivo terminal, tal como se ha descrito más arriba con respecto al bloque 602. El contexto de espera de SMS consiste en información relacionada con un reintento de una entrega de MT SMS desde al menos un SMS-SC al dispositivo terminal debido a un fallo en la entrega de MT SMS.
La Figura 18 es un diagrama de bloques que muestra una entidad UDR de acuerdo con una realización de la descripción. Como se muestra, la entidad UDR 1800 comprende un módulo 1802 de mantenimiento configurado para mantener, para un dispositivo terminal, un contexto de espera de SMS en respuesta a una solicitud procedente de una entidad UDM, tal como se ha descrito más arriba con respecto al bloque 1002. El contexto de espera de SMS consiste en información relacionada con un reintento de una entrega de MT SMS desde al menos un SMS-SC al dispositivo terminal debido a un fallo en la entrega de MT SMS. Los módulos arriba descritos pueden implementarse mediante hardware, software o una combinación de ambos.
En general, las diversas realizaciones ejemplares pueden implementarse en hardware o circuitos de uso especial, software, lógica o cualquier combinación de los mismos. Por ejemplo, algunos aspectos pueden implementarse en hardware, mientras que otros aspectos pueden implementarse en firmware o software que pueden ser ejecutados por un controlador, microprocesador u otro dispositivo informático, aunque la descripción no se limita a ello. Si bien varios aspectos de las realizaciones ejemplares de esta descripción se pueden ilustrar y describir como diagramas de bloques, diagramas de flujo o utilizando alguna otra representación gráfica, se entiende bien que estos bloques, aparatos, sistemas, técnicas o métodos descritos en la presente memoria se pueden implementar en, como ejemplos no limitativos, hardware, software, firmware, circuitos o lógica de uso especial, hardware o controlador de uso general u otros dispositivos informáticos, o alguna combinación de los mismos.
Como tal, se ha de entender que al menos algunos aspectos de las realizaciones ejemplares de la descripción pueden ponerse en práctica en diversos componentes tales como chips y módulos de circuitos integrados. Por lo tanto, se ha de entender que las realizaciones ejemplares de esta descripción pueden realizarse en un aparato incorporado como un circuito integrado, donde el circuito integrado puede comprender circuitos (así como posiblemente firmware) para incorporar al menos uno o más de un procesador de datos, un procesador de señales digitales, circuitos de banda base y circuitos de radiofrecuencia que son configurables para operar de acuerdo con las realizaciones ejemplares de esta descripción.
Se ha de entender que al menos algunos aspectos de las realizaciones ejemplares de la descripción pueden incorporarse en instrucciones ejecutables por ordenador, como en uno o más módulos de programa ejecutados por uno o más ordenadores u otros dispositivos. Generalmente, los módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos, etc. que realizan tareas particulares o implementan tipos de datos abstractos particulares cuando son ejecutados por un procesador en un ordenador u otro dispositivo. Las instrucciones ejecutables por ordenador pueden almacenarse en un medio legible por ordenador, como un disco duro, disco óptico, medios de almacenamiento extraíbles, memoria de estado sólido, RAM, etc. Como apreciará un experto en la técnica, la función de los módulos de programa puede combinarse o distribuirse según se desee en diversas realizaciones. Además, la función puede incorporarse totalmente o en parte en equivalentes de firmware o hardware tales como circuitos integrados, agrupaciones de puertas programables in situ (FPGA, por sus siglas en inglés), y similares.
Las referencias en la presente descripción a "una realización", "la realización", etc., indican que la realización descrita puede incluir un rasgo, estructura o característica particular, pero no es necesario que cada realización incluya el rasgo, estructura o característica particular. Por otro lado, dichas frases no se refieren necesariamente a la misma realización. Además, cuando se describe un rasgo, estructura o característica particular en relación con una realización, se afirma que está dentro del conocimiento de un experto en la técnica implementar dicho rasgo, estructura o característica en relación con otras realizaciones, independientemente de que se describa explícitamente o no.
Se ha de entender que, aunque los términos "primero", "segundo" y así sucesivamente pueden usarse en la presente memoria para describir varios elementos, estos elementos no deben estar limitados por estos términos. Estos términos solo se utilizan para distinguir un elemento de otro. Por ejemplo, un primer elemento podría designarse como segundo elemento y, de manera similar, un segundo elemento podría designarse como primer elemento, sin apartarse del alcance de la descripción. Tal como se utiliza en la presente memoria, la expresión "y/o" incluye todas y cada una de las combinaciones de uno o más de los términos asociados enumerados.
La terminología utilizada en la presente memoria tiene el único objetivo de describir realizaciones particulares y no pretende limitar la presente descripción. Tal como se utilizan en la presente memoria, las formas singulares "un", "una", "el" y “la” también incluyen las formas plurales, a menos que el contexto indique claramente lo contrario. También se entenderá que las expresiones "comprende", "que comprende", "tiene", "que tiene", "incluye" y/o "que incluye", cuando se usan en la presente memoria, especifican la presencia de características, elementos y/o componentes, pero no excluyen la presencia o adición de otra u otras características, elementos, componentes y/o combinaciones de los mismos. Las expresiones "conectar", "conecta", "que conecta" y/o "conectado" que se utilizan en la presente memoria cubren la conexión directa y/o indirecta entre dos elementos.
La presente descripción incluye cualquier característica o combinación de características novedosas descritas en la presente memoria, ya sea explícitamente o cualquier generalización de las mismas. Varias modificaciones y adaptaciones de las anteriores realizaciones ejemplares de esta descripción pueden resultar evidentes para los expertos en las técnicas relevantes en vista de la descripción anterior, cuando se lee junto con los dibujos adjuntos. Sin embargo, todas y cada una de las modificaciones seguirán estando dentro del alcance de las realizaciones ejemplares y no limitativas de esta descripción.

Claims (15)

REIVINDICACIONES
1. Un método realizado por una entidad (1600,1700) de gestión de datos unificados, UDM, que comprende: transmitir una solicitud HTTP a una entidad (1600, 1800) de repositorio de datos unificados, UDR, para mantener (602) un contexto de espera de servicio de mensajes cortos, SMS, para un dispositivo terminal, en la entidad UDR, en donde el contexto de espera de SMS consiste en información relacionada con un reintento de entrega de SMS con terminación en móvil, MT, desde al menos un centro de servicio de SMS, SMS-SC, al dispositivo terminal debido a un fallo en la entrega de MT SMS,
en donde el contexto de espera de SMS se mantiene mediante al menos una de las siguientes etapas:
- consultar a la entidad UDR sobre un contexto de espera de SMS para el dispositivo terminal, enviando una solicitud GET de protocolo de transferencia de hipertexto, HTTP, a la entidad UDR;
- crear un contexto de espera de SMS para el dispositivo terminal, enviando una solicitud HTTP PUT a la entidad UDR; y
- actualizar el contexto de espera de SMS para el dispositivo terminal, enviando una solicitud HTTP PUT o PATCH a la entidad UDR, y
en donde la solicitud HTTP PUT comprende el contexto de espera de SMS para el dispositivo terminal, y/o en donde la solicitud HTTP PATCH comprende una indicación que indica al menos uno de los contextos de espera de SMS para el dispositivo terminal.
2. El método de la reivindicación 1, en donde:
(a) el método comprende además recibir una respuesta HTTP GET en respuesta a la solicitud HTTP GET, en donde la respuesta HTTP GET comprende el contexto de espera de SMS para el dispositivo terminal; y/o
(b) el método comprende además alertar al, al menos un, SMS-SC de que el reintento de la entrega de MT SMS se puede iniciar para el dispositivo terminal, sobre la base del contexto de espera de SMS mantenido.
3. El método según la reivindicación 1, grupo de características (b), en donde:
- el método comprende además eliminar (906) el contexto de espera de SMS mantenido después de alertar al, al menos un, SMS-SC, en donde, opcionalmente, el contexto de espera de SMS mantenido se elimina de una entidad UDR; o
- la eliminación se realiza enviando una solicitud HTTP DELETE a la entidad UDR.
4. El método según cualquiera de las reivindicaciones 1 a 3, en donde el contexto de espera de SMS para el dispositivo terminal incluye al menos uno de:
una lista de una dirección del al menos un SMS-SC;
una lista de un tiempo de caducidad del al menos un SMS-SC hasta el cual es válido el reintento de la entrega del MT SMS por parte del al menos un SMS-SC;
un primer indicador que indica que un motivo para el fallo de la entrega de MT SMS consiste en que el dispositivo terminal no está accesible;
un segundo indicador que indica que el motivo del fallo de la entrega de MT SMS consiste en que se ha excedido la capacidad de memoria del dispositivo terminal;
un tercer indicador que indica un motivo para el reintento de la entrega del MT SMS;
un primer punto en el tiempo hasta el cual es válido el reintento de la entrega del MT SMS; y
un segundo punto en el tiempo hasta el cual es válido el segundo indicador,
en donde, opcionalmente, el tercer indicador tiene un primer valor que indica que el dispositivo terminal está accesible para el reintento, y/o un segundo valor que indica que el dispositivo terminal tiene memoria disponible para el reintento.
5. El método según la reivindicación 4, en donde mantener (602) el contexto de espera de SMS en la entidad UDR para el dispositivo terminal comprende:
en respuesta a la recepción de una información sobre un fallo en la entrega de MT SMS, consultar (708) a la entidad UDR sobre un contexto de espera de SMS para el dispositivo terminal;
cuando no ha habido un contexto de espera de SMS almacenado en la entidad UDR para el dispositivo terminal, crear (710) un contexto de espera de SMS en la entidad UDR para el dispositivo terminal; y
cuando ha habido un contexto de espera de SMS almacenado en la entidad UDR para el dispositivo terminal y el fallo de la entrega de MT SMS está relacionado con un SMS-SC diferente al del contexto de espera de SMS, actualizar (712) el contexto de espera de SMS en la entidad UDR para el dispositivo terminal.
6. El método según la reivindicación 5, en donde:
- la entidad UDM es informada de que el motivo del fallo de la entrega de MT SMS consiste en que el dispositivo terminal no está accesible; y en donde el contexto de espera de SMS creado o actualizado incluye el primer indicador; o
- la entidad UDM es informada de que el motivo del fallo de la entrega de MT SMS consiste en que se ha excedido la capacidad de memoria del dispositivo terminal; y en donde el contexto de espera de SMS creado o actualizado incluye el segundo indicador.
7. El método según la reivindicación 5 o 6, en donde mantener (602) el contexto de espera de SMS en la entidad UDR para el dispositivo terminal comprende:
en respuesta a un evento que indica que se puede iniciar el reintento, consultar (814) a la entidad UDR sobre el contexto de espera de SMS para el dispositivo terminal; y
actualizar (816) el contexto de espera de SMS en la entidad UDR para el dispositivo terminal.
8. El método según la reivindicación 7, en donde:
- el evento consiste en que se informa a la entidad UDM de que se puede acceder al dispositivo terminal; en donde el contexto de espera de SMS consultado incluye el primer indicador y no incluye el segundo indicador; y en donde el contexto de espera de SMS se actualiza en la entidad UDR eliminando el primer indicador del contexto de espera de SMS; o
- el evento consiste en que se informa a la entidad UDM de que el dispositivo terminal tiene memoria disponible para el reintento; en donde el contexto de espera de SMS consultado incluye el segundo indicador y no incluye el primer indicador; y en donde el contexto de espera de SMS se actualiza en la entidad UDR eliminando el segundo indicador del contexto de espera de SMS; o
- el evento consiste en que se informa a la entidad UDM de que el dispositivo terminal es accesible o tiene memoria disponible para el reintento; en donde el contexto de espera de SMS consultado no incluye el primer indicador ni el segundo indicador; y en donde el contexto de espera de SMS se actualiza en la entidad UDR agregando el tercer indicador y el primer punto en el tiempo en el contexto de espera de SMS.
9. Un método realizado por una entidad (1800) de repositorio de datos unificados, UDR, que comprende: mantener (1002), para un dispositivo terminal, un contexto de espera de servicio de mensajes cortos, SMS, en respuesta a una solicitud HTTP procedente de una entidad (1700) de gestión de datos unificados, UDM, en donde el contexto de espera de SMS consiste en información relacionada con un reintento de una entrega de SMS con terminación en móvil, MT, desde al menos un centro de servicio de SMS, SMS-SC, al dispositivo terminal debido a un fallo en la entrega de MT SMS,
en donde el contexto de espera de SMS se mantiene mediante al menos una de las siguientes etapas:
- responder a una consulta procedente de la entidad UDM sobre un contexto de espera de SMS para el dispositivo terminal, en donde la consulta consiste en una solicitud GET de protocolo de transferencia de hipertexto, HTTP; - crear el contexto de espera de SMS para el dispositivo terminal, mediante la recepción de una solicitud HTTP PUT procedente de la entidad UDM; y
- actualizar el contexto de espera de SMS para el dispositivo terminal, mediante la recepción de una solicitud HTTP PUT o PATCH procedente de la entidad u Dm , y
en donde la solicitud HTTP PUT comprende el contexto de espera de SMS para el dispositivo terminal, y/o en donde la solicitud HTTP PATCH comprende una indicación que indica al menos uno de los contextos de espera de SMS para el dispositivo terminal.
10. El método según la reivindicación 9, que además comprende:
eliminar (1104) el contexto de espera de SMS mantenido en respuesta a otra solicitud procedente de la entidad UDM, en donde, opcionalmente, la eliminación se realiza mediante la recepción de una solicitud HTTP DELETE procedente de la entidad UDM.
11. El método según la reivindicación 9 o 10, en donde el contexto de espera de SMS para el dispositivo terminal incluye al menos uno de:
una lista de una dirección del al menos un SMS-SC;
una lista de un tiempo de caducidad del al menos un SMS-SC hasta el cual es válido el reintento de la entrega del MT SMS por parte del al menos un SMS-SC;
un primer indicador que indica que un motivo para el fallo de la entrega de MT SMS consiste en que el dispositivo terminal no está accesible;
un segundo indicador que indica que el motivo del fallo de la entrega de MT SMS consiste en que se ha excedido la capacidad de memoria del dispositivo terminal;
un tercer indicador que indica un motivo para el reintento de la entrega del MT SMS;
un primer punto en el tiempo hasta el cual es válido el reintento de la entrega del MT SMS; y
un segundo punto en el tiempo hasta el cual es válido el segundo indicador,
en donde, opcionalmente, el tercer indicador tiene un primer valor que indica que el dispositivo terminal está accesible para el reintento, y/o un segundo valor que indica que el dispositivo terminal tiene memoria disponible para el reintento.
12. Un método implementado en un sistema de comunicación que incluye una entidad (1600,1700) de gestión de datos unificados, UDM, y una entidad (1600, 1800) de repositorio de datos unificados, UDR, que comprende: mantener (602), por medio de la entidad UDM, un contexto de espera de servicio de mensajes cortos, SMS, en la unidad UDR para un dispositivo terminal, en donde el contexto de espera de SMS consiste en información relacionada con un reintento de reintento de entrega de SMS con terminación en móvil, MT, desde al menos un centro de servicio de SMS, SMS-SC, al dispositivo terminal debido a un fallo en la entrega de MT SMS, en donde el contexto de espera de SMS se mantiene mediante al menos una de las siguientes etapas:
- consultar a la entidad UDR sobre un contexto de espera de SMS para el dispositivo terminal, enviando una solicitud GET de protocolo de transferencia de hipertexto, HTTP, a la entidad UDR;
- crear un contexto de espera de SMS para el dispositivo terminal, enviando una solicitud HTTP PUT a la entidad UDR; y
- actualizar el contexto de espera de SMS para el dispositivo terminal, enviando una solicitud HTTP PUT o PATCH a la entidad UDR, y
- en donde la solicitud HTTP PUT comprende el contexto de espera de SMS para el dispositivo terminal, y/o en donde la solicitud HTTP PATCH comprende una indicación que indica al menos uno de los contextos de espera de SMS para el dispositivo terminal;
en donde la entidad UDR mantiene (1002), para un dispositivo terminal, un contexto de espera de SMS en respuesta a una solicitud HTTP procedente de una entidad UDM, en donde el contexto de espera de SMS se mantiene mediante al menos una de las siguientes etapas:
- responder a la consulta procedente de la entidad UDM sobre un contexto de espera de SMS para el dispositivo terminal, en donde la consulta es la solicitud HTTP GET;
- crear un contexto de espera de SMS para el dispositivo terminal mediante la recepción de la solicitud HTTP PUT procedente de la entidad UDM; y
- actualizar el contexto de espera de SMS para el dispositivo terminal mediante la recepción de la solicitud HTTP PUT o PATCH procedente de la entidad UDM.
13. Una entidad (1600, 1700) gestión de datos unificados, UDM, que comprende:
al menos un procesador (1610); y
al menos una memoria (1620), conteniendo la al menos una memoria (1620) instrucciones ejecutables por el al menos un procesador (1610), por lo que la entidad (1600) UDM es operativa cuando ejecuta las instrucciones para realizar el método según cualquiera de las reivindicaciones 1 a 8.
14. Una entidad (1600, 1800) de repositorio de datos unificados, UDR, que comprende:
al menos un procesador (1610); y
al menos una memoria (1620), conteniendo la al menos una memoria (1620) Instrucciones ejecutables por el al menos un procesador (1610), por lo que la entidad (1600) UDR es operativa cuando ejecuta las instrucciones para realizar el método según cualquiera de las reivindicaciones 9 a 11.
15. Un medio de almacenamiento legible por ordenador, que comprende instrucciones que, cuando son ejecutadas por al menos un procesador, hace que el al menos un procesador realice el método según cualquiera de las reivindicaciones 1 a 12.
ES20781499T 2020-02-10 2020-09-28 Métodos y aparatos para la entrega de SMS Active ES2952593T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2020074635 2020-02-10
PCT/EP2020/077085 WO2021160299A1 (en) 2020-02-10 2020-09-28 Methods and apparatuses for sms delivery

Publications (1)

Publication Number Publication Date
ES2952593T3 true ES2952593T3 (es) 2023-11-02

Family

ID=72670723

Family Applications (1)

Application Number Title Priority Date Filing Date
ES20781499T Active ES2952593T3 (es) 2020-02-10 2020-09-28 Métodos y aparatos para la entrega de SMS

Country Status (7)

Country Link
US (1) US12185197B2 (es)
EP (2) EP4284039A3 (es)
JP (2) JP7345670B2 (es)
CN (1) CN115088278B (es)
ES (1) ES2952593T3 (es)
WO (1) WO2021160299A1 (es)
ZA (1) ZA202209731B (es)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021064714A1 (en) * 2019-10-03 2021-04-08 Telefonaktiebolaget Lm Ericsson (Publ) Support of network slicing for sms
CN116261107B (zh) * 2021-12-10 2025-04-22 中国电信股份有限公司 短信传输方法和系统、短信网关移动交换中心设备
US12526618B2 (en) * 2022-04-28 2026-01-13 T-Mobile Innovations Llc Accelerated user data messaging in a wireless communication network
US12574886B2 (en) * 2023-08-25 2026-03-10 T-Mobile Usa, Inc. Optimized registration and deregistration messaging with the SMSF and UDM

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SG154340A1 (en) * 2003-05-01 2009-08-28 Interdigital Tech Corp Delivery of data over wlan coupled to 3gpp
US8848604B2 (en) 2011-01-10 2014-09-30 Alcatel Lucent Application-originated text messages delivered over a packet-switched network
US10924895B2 (en) 2013-01-22 2021-02-16 Blackberry Limited Enhancing short message service addressing and routing
US10531420B2 (en) 2017-01-05 2020-01-07 Huawei Technologies Co., Ltd. Systems and methods for application-friendly protocol data unit (PDU) session management
WO2018236164A1 (ko) 2017-06-21 2018-12-27 엘지전자(주) 무선 통신 시스템에서 서비스 요청 절차 수행 방법 및 이를 위한 장치
CN108227652A (zh) 2017-12-21 2018-06-29 北京航空航天大学 一种基于MTConnect协议的能耗数据采集系统
WO2019220750A1 (en) 2018-05-18 2019-11-21 Nec Corporation Procedure to deliver sms to mobile device
CN110582062B (zh) * 2018-05-21 2020-12-08 华为技术有限公司 一种消息发送的方法及装置
CN111684826B (zh) 2018-06-25 2023-03-28 日本电气株式会社 在网络中的sms订阅改变时向ue指示sms订阅的方法和系统
US10932097B2 (en) * 2018-12-21 2021-02-23 Verizon Patent And Licensing Inc. Method and system of routing selection for SMS over NAS
US11997588B2 (en) * 2019-02-07 2024-05-28 Apple Inc. Enabling UAS service for identification and operation in 3GPP system
WO2020252337A1 (en) * 2019-06-12 2020-12-17 Apple Inc. Performance measurements related to application triggering and sms over nas
WO2021064714A1 (en) * 2019-10-03 2021-04-08 Telefonaktiebolaget Lm Ericsson (Publ) Support of network slicing for sms
US20230075951A1 (en) * 2020-02-07 2023-03-09 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for registration data retrieval
US11470454B2 (en) * 2020-07-28 2022-10-11 T-Mobile Usa, Inc. Systems and methods for improved access to user data
CA3208359A1 (en) * 2021-02-12 2022-08-18 Cheng Wang Method and apparatus for ue reachability event enhancements

Also Published As

Publication number Publication date
BR112022014931A2 (pt) 2022-09-20
EP4104463A1 (en) 2022-12-21
US12185197B2 (en) 2024-12-31
EP4284039A3 (en) 2024-02-21
EP4104463C0 (en) 2023-08-09
CN115088278B (zh) 2024-04-19
US20230308842A1 (en) 2023-09-28
EP4284039A2 (en) 2023-11-29
JP2023171738A (ja) 2023-12-05
JP7345670B2 (ja) 2023-09-15
JP2023516901A (ja) 2023-04-21
JP7546126B2 (ja) 2024-09-05
ZA202209731B (en) 2024-11-27
EP4104463B1 (en) 2023-08-09
WO2021160299A1 (en) 2021-08-19
CN115088278A (zh) 2022-09-20

Similar Documents

Publication Publication Date Title
ES2952593T3 (es) Métodos y aparatos para la entrega de SMS
US20240349037A1 (en) Procedure to update the parameters related to unified access control
US20240187968A1 (en) Method of user equipment (ue), method of access and mobility management function (amf), method of unified data management (udm), ue, amf and udm
ES3019939T3 (en) Method and apparatus for registration data retrieval
BR112020010540A2 (pt) Métodos em um primeiro e em um segundo nó de função de rede, aparelhos em um primeiro e em um segundo nó de função de rede, mídia de armazenamento legível por computador, e, produto de programa de computador.
US12192860B2 (en) Short message service (SMS) delivery
US12556900B2 (en) Methods and apparatuses for event monitoring
WO2019201038A1 (zh) 一种短消息服务能力更新方法、设备及装置
ES3014278T3 (en) Methods and apparatuses for policy control
WO2020215658A1 (en) Methods and apparatuses for tracing of terminal device
WO2020155177A1 (en) Methods and apparatuses for monitoring event service for group of terminal devices
BR112022014931B1 (pt) Entidades de gerenciamento e de repositório de dados unificados, métodos relacionados, método implementado em um sistema de comunicação e meio de armazenamento
US11647379B2 (en) Methods and apparatuses for exposure of monitoring event
WO2022152209A1 (en) Method and apparatus for routing information retrieval
WO2020221297A1 (en) Methods and apparatuses for configuration of monitoring for terminal device
EP4027750A1 (en) Stateless network architecture