System and method for delivering a trigger request to a device in a network

Abstract

The present disclosure provides a system (106) and a method (600) for delivering a trigger request to a device in a network (106) The method (600) comprises receiving (602) the trigger request from a node. The method (600) includes determining (604) whether the trigger request comprises a header corresponding to a device payload format. Further, the method (600) includes adding (606) an Information Element (IE) associated with a Data coding Scheme (DCS) corresponding to a payload format to the trigger request. The method (600) includes transmitting (608) the trigger request along with the added IE to a second network function (212) over a T4 interface. Further, the method (600) includes encoding (610) the received trigger request based on the DCS. The method (600) includes transmitting (612) the encoded trigger request to the device.

Description

SYSTEM AND METHOD FOR DELIVERING A TRIGGER REQUEST TO A DEVICE IN A NETWORKTECHNICAL FIELD

[0001] The present disclosure relates generally to the field of telecommunications. In particular, it relates to a system and a method for delivering a trigger request to a device in a network.DEFINITIONS

[0002] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used indicates otherwise.

[0003] The term “Internet Protocol (IP)” used hereinafter in the specification refers to the method or protocol by which data is sent from one device to another over the internet or an IP-based network.

[0004] The term “Short Message Service Center (SMSC)” used hereinafter in the specification refers to the network entity responsible for managing the transmission of SMS messages.

[0005] The term “Internet of Things (loT) device” used hereinafter in the specification refers to a physical device connected to the internet, capable of collecting and transmitting data, and performing specific tasks

[0006] The term “Service Capability Server (SCS)” used hereinafter in the specification refers to an external application server that communicates with loT devices through the mobile network.

[0007] The term “Application Server (AS)” used hereinafter in the specification refers to is a software platform that provides an environment for running and managingapplications. The AS acts as a middle layer between the user interface and the backend systems or databases.

[0008] The term “Service Capability Exposure Function (SCEF)” used hereinafter in the specification refers to the component within the network architecture that enables third-party applications, such as SCS or AS, to communicate with mobile devices securely.

[0009] The term “Data Coding Scheme (DCS)” used hereinafter in the specification refers to the format or encoding scheme that defines how the message payload is encoded before being transmitted.

[0010] The term “Trigger Payload” used hereinafter in the specification refers to the data or message content sent to the loT device to initiate a specific action. This payload contains the instructions or information that the receiving device needs to execute the command. The trigger payload is formatted according to the DCS to ensure compatibility with the decoding capabilities of the loT device.

[0011] The term “Application Function (AF)” used hereinafter in the specification refers to a component that provides specific application services, such as initiating trigger requests to devices through the network.

[0012] The term “Device Trigger Request” used hereinafter in the specification refers to the message or command initiated by an SCS / AS / AF to remotely activate or control an loT device. This request includes parameters such as device identifiers, payload, and DCS to ensure the device executes the desired action upon receipt of the message.

[0013] The term “Network Exposure Function (NEF)” used hereinafter in the specification is a key component of the 5G core network that securely exposes network services and capabilities to third-party applications or AF over Application Programming Interfaces (APIs).

[0014] The term “Hypertext Transfer Protocol (HTTP)” used hereinafter in the specification refers to the foundational protocol for data communication on the World Wide Web. The HTTP is an application-layer protocol that enables the exchange of information between clients (such as web browsers or application servers) and servers.

[0015] The term “Diameter Protocol” used hereinafter in the specification refers to an advanced network protocol primarily used for Authentication, Authorization, and Accounting (AAA) in IP-based networks.

[0016] The term “Cellular Internet of Things (CIoT)” refers to a specific type of loT network that utilizes cellular networks (like 4G, 5G, Long-Term Evolution Machine Type Communication (LTE-M), Narrowband-Internet of Things (NB-IoT) to connect devices to the Internet.

[0017] These definitions are in addition to those expressed in the art.BACKGROUND

[0018] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.

[0019] Machine-to-Machine (M2M) and Internet of Things (loT) services in networks often rely on SMS-based device triggering. An application server or Service Capability Server (SCS) sends a device trigger request via a Service Capability Exposure Function (SCEF) or similar exposure function towards a Short Message Service Centre (SMSC). The SMSC then delivers the trigger as an SMS to the target user equipment (UE) or loT device. For correct interpretation at the device, the SMS payload must be encoded using an appropriate Data Coding Scheme (DCS), which defines aspects such ascharacter set and binary versus text encoding. Standardized interfaces, such as the T4 interface between SCEF and SMSC, define various Information Elements (IES) or Attribute Value Pairs (A VPs) for carrying trigger-related information (for example, user identifier, trigger payload, validity time, priority, and application port). However, these interfaces typically do not define any explicit parameter that conveys the DCS associated with the device trigger payload. As a result, even if the originating application or SCS knows the exact payload format, this information is not explicitly communicated to the SMSC.

[0020] Due to the absence of an explicit DCS indication, the SMSC is forced to guess or assume the encoding. This becomes increasingly problematic when multiple loT services, devices, and payload formats are multiplexed over the same SCEF-SMSC infrastructure. A DCS chosen purely by default or heuristic may not match the encoding expected by the device, leading to corrupted payloads, failed triggering, misinterpretation of binary content, and increased operational effort for debugging and reconfiguration.

[0021] In conventional deployments, operators typically address the limitations using static or semi-static configuration at the SMSC. For example, a fixed DCS value may be provisioned per service, per SCS, or per sender address, and applied to all related device trigger messages. Some implementations attempt to infer the DCS by inspecting the payload or by constraining all participating applications to use a limited set of formats that align with the preconfigured DCS values. In certain cases, payload format hints may be exchanged between the application server and the SCEF using proprietary headers or parameters. However, because the standardized SCEF-SMSC interface does not carry a corresponding DCS field, the information remains local and does not reliably influence the encoding behavior of the SMSC.

[0022] Hence, a method and system that can address the shortcomings of existing solutions are needed.SUMMARY OF THE DISCLOSURE

[0023] In an embodiment, a method for delivering a trigger request to a device in a network is described. The method includes receiving the trigger request from a node. The method includes determining whether the trigger request includes a header corresponding to a device pay load format. Upon the determining that the trigger request includes the header, the method further include adding an Information Element (IE) associated with a Data coding Scheme (DCS) corresponding to a payload format to the trigger request. Further, the method includes transmitting the trigger request along with the added IE to a second network function over a T4 interface. The method includes encoding the received trigger request based on the DCS. The method includes transmitting the encoded trigger request to the device.

[0024] In an embodiment, the first network function includes at least one of a Service Capability Exposure Function (SCEF), a Network Exposure Function (NEF), or a Machine Type Communication-Interworking Function (MTC-IWF).

[0025] In another embodiment, the second network function comprises a Short Message Service Centre (SMSC).

[0026] In another embodiment, the DCS is an Attribute Value Pair (A VP) contained in the header associated with the device payload format.

[0027] In another embodiment, upon determining that the trigger request does not comprise the header, the method include retrieving a predefined DCS based on one or more configurations associated with the node. The one or more configurations are provided by a user at a time of provisioning of the node, and the node includes one of a Services Capability Server (SCS), an Application Server (AS), and an Application Function (AF). The method includes enriching the trigger request with the retrieved predefined DCS. Further, the method includes transmitting the enriched trigger request to the second network function.

[0028] In another exemplary embodiment, a system for delivering a trigger request to a device in a network is described. The system includes a first network function configured to receive the trigger request from a node. Further, the first network function is configured to determine whether the trigger request includes a header corresponding to a device pay load format. If the trigger request includes the header, the first network function is configured to add an Information Element (IE) associated with a Data coding Scheme (DCS) corresponding to a payload format to the trigger request. The first network function is configured to transmit the trigger request along with the added IE to a second network function over a T4 interface. Further, the system includes the second network function configured to encode the received trigger request based on the DCS. The second network function is configured to transmit the encoded trigger request to the device.

[0029] In another embodiment, a user equipment (UE) communicatively coupled with a system in a network. The coupling includes receiving a connection request from the UE. Further, the coupling includes sending an acknowledgment of the connection request to the UE. Further, the coupling includes transmitting a plurality of signals in response to the connection request. The system is configured to receive trigger request by the UE in the network.OBJECTIVES OF THE DISCLOSURE

[0030] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:

[0031] An objective of the present disclosure is to provide a system and a method for improving delivery of device trigger requests in a network.

[0032] Another objective of the present disclosure is to provide a system and a method for ensuring the accurate encoding of the device trigger pay load by providing necessary Data Coding Scheme (DSC) information.

[0033] Yet another objective of the present disclosure is to provide a system and a method to improve the efficiency and reliability of device trigger delivery by optimizing the communication between network functions.

[0034] Yet another objective of the present disclosure is to provide a system and a method for providing a solution that can accommodate various device payload formats and data coding schemes.

[0035] Other objectives and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING

[0036] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals, refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale; emphasis is instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components, electronic components, or circuitry commonly used to implement such components.

[0037] FIG. 1 illustrates an exemplary network architecture of a system for delivering a trigger request to a device in a network, in accordance with an embodiment of the present disclosure.

[0038] FIG. 2 illustrates an exemplary block diagram of the system for delivering the trigger request to the device in the network, in accordance with an embodiment of the present disclosure.

[0039] FIG. 3 illustrates an exemplary diagram of a system architecture for delivering the trigger request to the device in the network, in accordance with an embodiment of the present disclosure.

[0040] FIG. 4 illustrates an exemplary flow diagram for delivering the trigger request to the device in the network, in accordance with an embodiment of the present disclosure, in accordance with an embodiment of the present disclosure.

[0041] FIG. 5 illustrates an exemplary flow diagram for delivering the trigger request to the device in the network, in accordance with an embodiment of the present disclosure, in accordance with an embodiment of the present disclosure.

[0042] FIG. 6 illustrates an exemplary flow diagram of a method for delivering the trigger request to the device in the network, in accordance with an embodiment of the present disclosure, in accordance with an embodiment of the present disclosure.

[0043] FIG. 7 illustrates an example computer system in which or with which the embodiments of the present disclosure may be implemented.

[0044] The foregoing shall be more apparent from the following more detailed description of the disclosure.LIST OF REFERENCE NUMERALS100 - Network architecture102-1, 102-2... 102-N-User(s)104-1, 104-2... 104-N - User equipment(s)106 - Network108 - System200 - Block diagram202 - One or more processor(s)204 - Memory206 - Interface(s)208 - First network function210 - Database212 - Second network function300 - System Architecture302 - Service Capability Server / Application Server / Application Function (SCS / AS / AF)304 - Provisioning gateway User Interface (UI)306 - Elastic Load Balancer (ELB)308 - Cellular Internet of Things (eloT) (Service Capability Exposure Function (SCEF) / Network Exposure Function (NEF) + Machine Type Communication-Interworking Function (MTC-IWF))310 - Short Message Service Center (SMSC)312 - Internet of Things (loT) device400 - Flow diagram500 - Flow diagram600 - Method700 - Computer system710 - External Storage Device720 - Bus730 - Main Memory740 - Read Only Memory750 - Mass Storage Device760 - Communication Port770 - ProcessorDETAILED DESCRIPTION

[0045] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.

[0046] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function andarrangement of elements without departing from the spirit and scope of the disclosure as set forth.

[0047] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0048] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0049] The word “exemplary” and / or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and / or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, suchterms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.

[0050] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0051] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any combinations of one or more of the associated listed items. It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein.

[0052] While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment, as well as other embodiments of the disclosure, will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.

[0053] Wireless communication technology has rapidly evolved over the past few decades. The first generation of wireless communication technology was analog, offering only voice services. Further, text messaging and data services became possible when the second-generation (2G) technology was introduced. The third generation (3G) technology marked the introduction of high-speed internet access, mobile video calling, and location-based services. The fourth generation (4G) technology revolutionized the wireless communication with faster data speeds, improved network coverage, and security. Currently, fifth generation (5G) technology is being deployed, offering significantly faster data speeds, lower latency, and the ability to connect many devices simultaneously. Further, 6G successor to 5G is expected to provide significantly high data speed with reduced latency, which may offer improved connectivity for a vast number of devices concurrently. The capabilities of 6G enable new types of applications and services, such as advanced augmented reality (AR) and virtual reality (VR), holographic communications, and more immersive digital experiences. These advancements represent a significant leap forward from previous generations, enabling enhanced mobile broadband, improved Internet of Things (loT) connectivity, and more efficient use of network resources. The sixth generation (6G) technology promises to build upon these advancements, pushing the boundaries of wireless communication even further. While the 5G technology is still being rolled outglobally, research and development into the 6G are rapidly progressing, with the aim of revolutionizing the way of connecting and interacting with technology.

[0054] In M2M / IoT deployments, application servers typically trigger devices via a SCS / SCEF towards an SMSC, which finally delivers an SMS-based device trigger to the UE / IoT device. The UE interprets the trigger based on the Data Coding Scheme (DCS) set in the SMS TPDU. However, the standardized T4 interface between SCEF and SMSC does not define any explicit parameter to convey the DCS or payload encoding type along with the device trigger request. As a result, even if the upstream application or SCEF knows the exact payload format (for example, binary, UCS2, GSM 7-bit), the information is not passed in a structured way to the SMSC. The SMSC applies a default or guessed DCS, which often leads to mis-encoded triggers, corrupted payloads, failed activations, and high operational overhead whenever new services, devices, or payload types are introduced.

[0055] Conventional approaches work around the limitations with local and static configuration in the SMSC. Operators typically assign a fixed DCS per SCS / service / SMS origin address and rely on this mapping for all associated device triggers. Some implementations attempt heuristic inspection of the payload at the SMSC to infer a suitable DCS, or they constrain applications to a very limited, preagreed set of encodings that align with the SMSC defaults. In a few cases, format hints may be exchanged between the application and the SCEF using proprietary headers, but the hints are not propagated over the standardized T4 interface and do not reliably influence SMSC behavior. The conventional approaches are rigid, error-prone, and difficult to scale across heterogeneous loT fleets and evolving payload formats.

[0056] The present disclosure introduces an explicit enrichment of the device trigger signaling path with DCS-related information. When the application or SCS invokes a device trigger towards the SCEF, it supplies a payload format indication (for example via a “devicePayloadFormaf ’ or equivalent parameter). The SCEF maps this indicationto a corresponding DCS or encoding descriptor using configurable profiles and embeds this information as a dedicated IE / AVP in the device trigger request sent over the T4 (or equivalent) interface towards the SMSC. The SMSC, upon receiving the enriched request, reads the DCS indication and applies the indicated coding scheme when constructing the SMS TPDU for the device trigger, with defined fallback behavior when the indication is absent or unsupported. The present disclosure provides a standardized, end-to-end way to align payload format and DCS, reduces mis-encoding, simplifies onboarding of new services, and remains backward compatible because legacy SMSCs may ignore the new IE / AVP. The various embodiments throughout the disclosure will be explained in more detail with reference to FIGS. 1- 7.

[0057] FIG. 1 illustrates an exemplary network architecture (100) of a system (108) for delivering the device trigger request in the network (106), in accordance with an embodiment of the present disclosure.

[0058] As illustrated in FIG. 1, the network architecture (100) may include one or more user equipments (UEs) (104-1, 104-2... 104-N) associated with one or more users (102-1, 102-2... 102-N) in an environment. A person of ordinary skill in the art will understand that one or more users (102-1, 102-2... 102-N) may collectively referred to as the users (102). Similarly, a person of ordinary skill in the art will understand that one or more UEs (104-1, 104-2... 104-N) may be collectively referred to as the UE (104). Although only three UEs (104) are depicted in FIG. 1, however, any number of the UE (104) may be included without departing from the scope of the ongoing description. In an example, the UE (104) may be an Internet of Things (loT) device.

[0059] In an embodiment, the UE (104) may include smart devices operating in a smart environment, for example, an Internet of Things (loT) system. In such an embodiment, the UE (104) may include, but is not limited to, smartphones, smart watches, smart sensors (e.g., mechanical, thermal, electrical, magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices,networked vehicle accessories, networked vehicular devices, smart accessories, tablets, smart television (TV), computers, smart security system, smart home system, other devices for monitoring or interacting with or for the users (102) and / or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE (104) may include, but not limited to, intelligent, multi-sensing, network-connected devices, that may integrate seamlessly with each other and / or with a central server or a cloud-computing system or any other device that is network-connected.

[0060] Additionally, in some embodiments, the UE (104) may include, but is not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a tablet device, and so on), a wearable computer device (e.g., a headmounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and / or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UE (104) may include, but is not limited to, any electrical, electronic, electromechanical, or equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device, wherein the UE (104) may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user (102) or the entity such as touchpad, touch-enabled screen, electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE (104) may not be restricted to the mentioned devices and various other devices may be used.

[0061] Referring to FIG. 1, the UE (104) may communicate with the system (108) through the network (wireless communication network) (106) for sending or receiving various types of data. In an embodiment, the network (106) may include at least one ofa fifth generation (5G) network, sixth generation (6G) network, or the like. The network (106) may enable the UE (104) to communicate with other devices in the network architecture (100) and / or with the system (108). The network (106) may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network (106) may be implemented as, or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like.

[0062] In an embodiment, the network (106) may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network (106) may also include, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.

[0063] In an embodiment, the UE (104) is communicatively coupled with the network (106). The network (106) may receive a connection request from the UE (104). The network (106) may send an acknowledgment of the connection request to the UE (104). The UE ( 104) may transmit a plurality of signals in response to the connection request.

[0064] In an embodiment, the system (108) receive the trigger request from a node. The system (108) determine whether the trigger request comprises a header corresponding to a device pay load format. Upon the determining that the trigger request comprises the header, the system (108) add an Information Element (IE) associatedwith a Data coding Scheme (DCS) corresponding to a payload format to the trigger request. Further, the system (108) may transmit the trigger request along with the added IE to a second network function over a T4 interface. The system (108) encodes the received trigger request based on the DCS. Further, the system (108) may transmit the encoded trigger request to the device.

[0065] Although FIG. 1 shows exemplary components of the network architecture (100), in other embodiments, the network architecture (100) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture (100) may perform functions described as being performed by one or more other components of the network architecture (100).

[0066] FIG. 2 illustrates an exemplary block diagram (200) of the system (108) for delivering the trigger request to the device in the network (106), in accordance with an embodiment of the present disclosure. FIG. 2 is explained in conjunction with the FIG.1.

[0067] In an embodiment, the system (108) may include a processor (202). The processor (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and / or any devices that process data based on operational instructions. Among other capabilities, the processor (202) may be configured to fetch and execute computer-readable instructions stored in a memory (204) of the system (108). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory (204) may include any non-transitory storage device including, for example, volatile memory such as random-access memory (RAM), or non-volatile memory such as erasable programmable read only memory (EPROM), flash memory, and the like.

[0068] In an embodiment, the system (108) may include an interface (206). The interface (206) may include a variety of interfaces, for example, interfaces for data input and output devices (I / O), storage devices, and the like. The interface (206) may facilitate communication through the system (108). The interface (206) may also provide a communication pathway for one or more components of the system (108). Examples of such components include, but are not limited to, a processor (202) and a database (210).

[0069] In an embodiment, the processor (202) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the first network function (208) and a second network function (212). In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processor (202) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processor (202) may comprise a processing resource to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processor (202). In such examples, the system (108) may comprise the machine- readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system and the one or more processors (202). In other examples, the processor (202) may be implemented by electronic circuitry. In an embodiment, the processor (202) may be implemented in the first network function (208) and the second network function (212). the first network function (208) includes at least one of a Service Capability Exposure Function (SCEF), a Network Exposure Function (NEF), or a Machine Type Communication-Interworking Function (MTC-IWF). Further, the second network function (212) includes a Short Message Service Centre (SMSC).

[0070] In an embodiment, the first network function (208) receives a trigger request / Device Trigger Request (DTR) from a node. The node may be, for example, an application server, a Service Capability Server (SCS), a Service Capability Exposure Function (SCEF), a Network Exposure Function (NEF), a messaging node such as a Short Message Service Centre (SMSC), or any other network function capable of initiating a device trigger towards the UE (104) or machine- type device. The trigger request contains instructions or payload data intended to be delivered to an Internet of Things (loT) device. The trigger request initiates the process by communicating the intention of the application server to trigger specific actions or updates on the target loT device. The Device Trigger Request (DTR) is received over a predefined interface or Application Programming Interface (API), such as a Diameter-based, HTTP / REST-based, or proprietary signaling interface, using one or more standardized or operatorspecific protocols. Upon reception, the first network function (208) decodes and parses the DTR to extract one or more parameters associated with the device trigger. The one or more parameters may include, for example, a device or subscriber identifier, an application identifier, a trigger payload or reference to the payload, a priority indication, validity time, service-related attributes, and any additional metadata provided by the originating node. The first network function (208) may further perform preliminary validation and integrity checks on the DTR, such as verifying that mandatory fields are present, checking a digital signature or authentication token, and correlating the received DTR with a configured service profile or policy associated with the originating node or target device.

[0071] Further, the first network function (208) may determine whether the trigger request includes a header corresponding to a device payload format. Once the trigger request is received, the first network function (208) is configured to inspect the signaling information of the trigger request to determine whether it carries a header corresponding to a device payload format. The header may be present, for example, in an application-layer message (such as an HTTP / REST header, JSON field, XML tag,or Diameter AVP) and may be provisioned under a predefined name or key agreed between the originating node and the operator (for instance, a “devicePay loadFormat” header or an equivalent indicator). The first network function (208) may parse the trigger request message structure, iterate through the set of headers or information elements, and compare each header name or identifier with a stored list of header names that are recognized as payload format indicators. In some implementations, the comparison may be performed in a case-insensitive manner and may support aliases or versioned header names. If a matching header is found, the processing engine 208 identifies that the trigger request includes an explicit device payload format indication and retrieves the associated value for subsequent processing. If no such header is found, the first network function (208) may determine that the trigger request does not contain an explicit device payload format header and may mark the request accordingly for handling based on default or fallback logic as configured in the system (100). In some embodiments, the first network function (208) inspects the trigger request to check if it includes the DCS related to the device payload format. The DCS specifies the format and encoding requirements for the payload data, ensuring the first network function (208) may verify whether the trigger request is fully equipped with the necessary data coding information for proper encoding.

[0072] Upon the determining that the trigger request includes the header, the first network function (208) is configured to add an Information Element (IE) associated with a Data coding Scheme (DCS) corresponding to a payload format to the trigger request. The first network function (208) reads the payload format value from the header, consults the mapping, and derives the appropriate DCS value. Based on this, the first network function (208) constructs the IE dedicated to DCS signaling, including at least an identifier field indicating that the IE relates to DCS and a value field carrying the derived DCS value. The IE is then added to the trigger request in accordance with the encoding rules of the underlying protocol, for example as an additional Diameter AVP, TLV field, JSON field, or XML element, without modifying the original payloadcontent. By embedding the DCS IE directly into the enriched DTR, the first network function (208) ensures that downstream nodes, such as an SMSC or equivalent messaging node, receive an explicit, machine-interpretable indication of the DCS to be applied when encoding the SMS or device trigger towards the target device.

[0073] Further, the first network function (208) is configured to transmit the trigger request along with the added IE to a second network function (212) over a T4 interface. The T4 interface provides a standardized communication pathway designed for securely transmitting enriched DTRs containing critical encoding instructions, ensuring they reach the SMSC with minimal delay or data alteration. The T4 interface also ensures compatibility in format and protocol, enabling the SMSC to interpret the DTR without needing additional adjustments or transformations. The T4 interface serves as a standardized communication channel between the first network function (208) and the second network function (212), ensuring the trigger request is transferred with the necessary data coding scheme for immediate processing and encoding by the SMSC. After enriching the trigger request (DTR) with the IE associated with the DCS, the processing engine 208 is configured to forward the updated trigger request to the second network function (212) over the T4 interface. The second network function (212) may be, for example, a Short Message Service Centre (SMSC) or any other messaging node responsible for constructing and delivering an SMS-based device trigger towards a user equipment or machine-type device. For this purpose, the first network function (208) may first encapsulate the trigger request, including the added DCS IE, in accordance with the protocol used on the T4 interface, such as a Diameterbased application or an equivalent standardized or operator-specific protocol. The first network function (208) may determine routing information for the second network function (212) based on one or more parameters associated with the trigger request, such as the serving PLMN, service profile, or configuration of the originating node, and may establish or utilize an existing secure transport association (for example, over TCP / TLS or SCTP / TLS). The enriched trigger request is then transmitted over the T4interface with the DCS IE encoded as a dedicated AVP or protocol-specific field, while preserving all other trigger-related parameters. In some embodiments, the first network function (208) may also perform transmission control functions such as retry, timeout handling, and error logging in case of delivery failures, ensuring that the second network function (212) reliably receives the complete trigger request along with the explicit DCS indication for subsequent processing.

[0074] In an embodiment, the second network function (212) is configured to encode the received trigger request based on the DCS. The second network function (212) first retrieves the DCS value from the added IE and selects an encoding profile corresponding to that DCS. The encoding profile may define, for example, whether the payload is to be treated as GSM 7-bit default alphabet text, UCS2 (16-bit) text, or binary user data, and may further specify character mapping rules, packing rules, and length constraints. The second network function (212) then processes the trigger payload contained in the trigger request accordingly. In case of a text payload, the second network function (212) converts the characters into the appropriate coded representation (for example, packing GSM 7-bit characters into octets or encoding Unicode characters into UCS2), and, where required, constructs any user data header fields such as application port addressing. In case of a binary payload format, the second network function (212) preserves the payload octets and applies the DCS to indicate binary content without altering the semantic structure of the data. Further, the second network function (212) may populate a corresponding DCS field in a message structure to be used by the downstream messaging node (for example, an SMS TPDU or an equivalent internal representation), ensuring that both the payload and the DCS are aligned. In some embodiments, the second network function (212) may perform validation to ensure that the payload is compatible with the selected DCS, apply segmentation rules if the encoded payload exceeds a maximum length, and generate error or fallback handling if the DCS is unsupported or inconsistent with the configured service profile, enabling the trigger request to be encoded in a manner that accuratelyreflects the intended payload format for the target device. In some embodiments, upon receiving the enriched trigger request over the T4 interface, the SMSC begins encoding the device trigger request based on the provided DCS. The encoding aligns the payload with the requirements of the loT device for proper data interpretation. Once encoding is complete, the SMSC delivers the encoded DTR to the target loT device, ensuring the payload arrives in a usable and compatible format.

[0075] Further, the second network function (212) is configured to transmit the encoded trigger request to the device. The second network function (212) may first construct a delivery-ready message structure, such as an SMS TPDU or an equivalent trigger container, including at least the encoded payload, the corresponding DCS value, and addressing information identifying the target device (for example, a subscriber number, IMSI, or device identifier). The second network function (212) then selects an appropriate delivery path based on a service profile or network configuration, such as SMS over circuit-switched domain, SMS over packet-switched domain, or an loT-specific trigger bearer, and forwards the encoded trigger request to a serving messaging node or access node (for example, an SMSC, IP-SM gateway, or base station) for over-the-air transmission to the device. In some embodiments, the second network function (212) may also apply concatenation headers and sequence numbers if the encoded trigger exceeds a single message size, manage retry and timeout procedures when acknowledgements or delivery reports are not received within a configured interval, and log transmission status for charging, auditing, or diagnostics. By transmitting the encoded trigger request, the second network function (212) ensures that the device receives the payload together with the correct DCS, enabling the device to interpret and process the trigger as intended.

[0076] Upon determining that the trigger request does not include the header, the first network function (208) is configured to retrieve a predefined DCS based on one or more configurations associated with the node. The one or more configurations are provided by a user at a time of provisioning of the node, and the node includes one ofa Services Capability Server (SCS), an Application Server (AS), and an Application Function (AF). The one or more configurations are specific to each application server and define the required coding schemes based on prior provisioning or default settings. The first network function (208) is configured to enrich trigger request with the retrieved predefined DCS. Further, the first network function (208) is configured to transmit the enriched trigger request to the second network function. The first network function (208) is configured to fall back to one or more predefined configurations associated with the originating node. The originating node is one of a Service Capability Server (SCS), an Application Server (AS), or an Application Function (AF) that initiates device trigger requests towards the network. During provisioning or onboarding of such a node, an operator or administrator configures, via a management interface, one or more parameters that define a default or “predefined” Data Coding Scheme (DCS) to be used for triggers originating from that node. The parameters may include, for example, a DCS value per node, per service identifier, or per applicationlevel endpoint. The first network function (208) maintains the configurations in a local or central configuration store and associates them with an identifier of the node, such as a node name, realm, IP address, or client identifier used on the signaling interface. When the trigger request without the payload format header is received, the first network function (208) identifies the originating node, consults the configuration store, and retrieves the predefined DCS corresponding to that node and, optionally, its service context. The first network function (208) then enriches the trigger request by adding the IE or field carrying the retrieved DCS value, in accordance with the encoding rules of the protocol used towards the second network function (for example, as an additional A VP on the T4 interface). Thus, even though the originating SCS / AS / AF did not explicitly indicate the payload format in the trigger request, the enriched trigger request still carries a clear DCS indication. Subsequently, the first network function (208) is configured to transmit the enriched trigger request, now including the predefined DCS IE, to the second network function over the T4 (or equivalent) interface. The secondnetwork function (212), such as an SMSC or messaging node, may then use the DCS indication to correctly encode the SMS or device trigger towards the device, ensuring consistent behavior even for legacy or non-upgraded SCS / AS / AFs that do not yet send the payload format header.

[0077] In an embodiment, the database (210) includes data that may be either stored or generated as a result of functionalities implemented by any of the components of the first network function (208) and the second network function (212).

[0078] Although FIG. 2A shows exemplary components of the system (108), in other embodiments, the system (108) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 2A. Additionally, or alternatively, one or more components of the system (108) may perform functions described as being performed by one or more other components of the system (108).

[0079] FIG. 3 illustrates an exemplary system architecture (300) configured for delivering the trigger request to the device in the network (106), in accordance with an embodiment of the present disclosure. FIG. 3 explains a multi-step process for delivering a Device Trigger Request (DTR) to an loT device over the network, showing the interaction between components: a provisioning gateway User Interface (UI) (304), an Elastic Load Balancer (ELB) (306), the Service Capability Server / Application Server / Application Function (SCS / AS / AF) (302), the Cellular Internet of Things (eloT) (Service Capability Exposure Function (SCEF) / Network Exposure Function (NEF) + Machine Type Communication-Interworking Function (MTC-IWF)) (308), the Short Message Service Center (SMSC) (310), and the loT Device. Each component performs a specific function in the overall process.

[0080] The provisioning gateway UI (304) is used to provision the SCS / AS (302) and all the configurations that SCEF (308) requires with respect to that SCS / AS (302). In an embodiment, the provisioning gateway UI (304) serves as the entry point for settingup configurations for the SCS / AS (302). When the SCS / AS (302) needs to be integrated into the system (108), the provisioning gateway UI (304) configures the SCS / AS (302) with essential settings required by the SCEF (308) to process future requests. The configurations may include default data coding schemes (DCS) values and device payload format specifications that the SCEF (308) will reference when handling device trigger requests from the SCS / AS (302). The configurations are crucial for the SCEF (308) to accurately process and deliver device trigger requests.

[0081] In an embodiment, the ELB (306) is responsible for distributing incoming provisioning requests across the SCEF (308). In examples, the ELB (306) may load balance the provisioning requests towards SCEF instances (308). When the provisioning gateway UI (304) initiates a provisioning request for the SCS / AS (302), the ELB (306) ensures that the workload is balanced by routing the incoming provisioning requests towards the eloT (SCEF / NEF + MTC-IWF) (308) or SCEF (308) instances. The ELB (306) helps in maintaining the system (108) efficiency by preventing any single SCEF instance from becoming overloaded and ensures that each instance can handle requests smoothly, leading to quicker processing and improved system performance.

[0082] In an embodiment, the SCS / AS / AF (302) is the origin point for the DTR destined for loT devices. The SCS / AS / AF (302) initiates the device trigger create / replace request, which is to be delivered to the loT device (312). Once provisioned, the SCS / AS / AF (302) can initiate the DTR, which contains instructions or payload data that the loT device (312) needs to process. The DTR may represent various actions, such as updates or configuration changes on the device. The SCS / AS / AF (302) sends this request to the SCEF (308), which will then handle its processing and forwarding, ensuring that the payload is correctly formatted for the loT device (310). The SCEF (308) will check whether the device payload format is provided in the request. If not, the SCEF (308) will fetch that information from the configurations provided while provisioning the SCS / AS / AF (302). The SCEF (308)will initiate the device trigger towards the SMSC (310) with appropriate DCS in the Data coding scheme AVP over the T4 interface as per the above condition related to the device payload format and all the other relevant information. The SMSC (310) will encode the device trigger payload as per the received DCS AVP and deliver the device trigger request to the loT device.

[0083] In an embodiment, the eloT (SCEF / NEF + MTC-IWF) (308) represents the core loT network functions involved in processing and delivering the device trigger request. The eloT (SCEF / NEF + MTC-IWF) (308) receives the device trigger request from the SCS / AS / AF (302). The SCS / AS / AF (302) determines the appropriate DCS based on the device payload format, either from the request itself or from configurations. The eloT (SCEF / NEF + MTC-IWF) (308) then enriches the device trigger request with the determined DCS and forwards it to the SMSC (310). The NEF is responsible for managing network resources and providing network services to loT devices. In the context of device trigger requests, the NEF may route the requests to the appropriate network elements. The MTC-IWF is a specialized function that handles the interworking between various networks. The MTC-IWF may be involved in translating and forwarding device trigger requests between different network domains. The eloT (SCEF / NEF + MTC-IWF) (308) will check whether device payload format is provided in the request if not. The eloT (SCEF / NEF + MTC-IWF) (308) will fetch that information from the configurations provided while provisioning the DCS values.

[0084] In an aspect, the eloT (SCEF / NEF + MTC-IWF) (308) sends appropriate DCS in Data Coding Scheme- Attribute Value Pair (DCS-AVP) over the T4 interface as per above condition or a ‘devicePayloadFormat’ custom header received from corresponding SCS / AS / AF (302) or a default DCS in case the above detail is not received thus, enhancing the flow to cover various data coding schemes available in the network (106).

[0085] In an embodiment, the SMSC (310) receives the enriched DTR from the eloT (SCEF / NEF + MTC-IWF) (308) over the T4 interface, now containing the correct DCS information. The SMSC (310) will encode the device trigger payload as per received DCS-AVP and deliver device trigger request to the loT device (312). The SMSC (310) uses the provided DCS to encode the device trigger pay load and then delivers the encoded message to the loT device (312). The SMSC (310) ensures that the device trigger request is delivered reliably and efficiently.

[0086] In an embodiment, the loT Device (312) is the final destination of the enriched DTR. After the SMSC (310) delivers the delivery report answer, the loT device (312) receives the encoded payload and processes it as instructed. Depending on the payload data, the loT Device (312) may perform actions such as updating its settings, executing a command, or changing its configuration. The loT device (312) may then generate a response, or further actions based on the received delivery report answer.

[0087] FIG. 4 illustrates an exemplary flow diagram of a method (400) for delivering the trigger request to the device in the network (106), in accordance with an embodiment of the present disclosure. The method (400) is performed by the system (108). FIG. 4 is explained in conjunction with FIGS. 1, 2, and 3.

[0088] At 402, the method (400) begins with the Service Capability Server / Application Server / Application Function (SCS / AS / AF) (302) to initiate a Trigger Submit Request to the Cellular Internet of Things (eloT) (Service Capability Exposure Function (SCEF) / Network Exposure Function (NEF) + Machine Type Communication-Interworking Function (MTC-IWF)) (308) over a Hyper Text Transfer Protocol (HTTP). In an aspect, the eloT (SCEF / NEF + MTC-IWF) (308) sends appropriate DCS in Data Coding Scheme- Attribute Value Pair (DCS-AVP) over the T4 interface as per above condition or a ‘ devicePay loadFormat’ custom header received from corresponding SCS / AS / AF (302). The trigger submit request includes a set of parameters such as:• Self: A server-assigned resource reference (typically a URI) that uniquely identifies this trigger submission instance for later retrieval / tracking.• externalld: An external identifier of the target device / subscriber (used when the device is addressed via an external identifier rather than a phone number / IMSI).• Msisdn: The target device’s MSISDN (international ISDN number / phone number) used to route the trigger to the correct UE / IoT device.• supportedFeatures: Feature negotiation bitmap / list indicating which optional capabilities are supported by the originator (and / or expected by the receiver) for this API invocation.• validityPeriod: The time window (absolute or relative) for which the trigger request remains valid; after expiry, the network should not attempt delivery.• Priority: A priority indication used by network nodes (e.g., SCEF / SMSC) to influence scheduling / handling versus other trigger requests.• applicationPortld and appSrcPortld: Application-layer port addressing values (destination / source) used for SMS User Data Header (UDH)-based port routing, so the trigger reaches the correct application on the device.• triggerPay load: The actual payload to be delivered to the device (command / data), this is what ultimately gets encoded and carried toward the UE / IoT device.• notificationDestination: Callback destination (e.g., an HTTP endpoint / URL) where delivery status and / or related notifications should be sent.• requestTestNotification: A flag requesting a “test” notification (commonly used to validate the notificationDestination / channel configuration without waiting for an actual delivery event).• websockNotifConfig: WebSocket notification configuration (e.g., WS endpoint / topic / auth parameters) when notifications are to be delivered over a WebSocket channel instead of (or in addition to) HTTP callbacks.• deliveryResult: Delivery reporting control / data — used to request delivery reporting and / or to carry the delivery outcome / status details when reporting back.

[0089] The eloT (SCEF / NEF + MTC-IWF) (308) processes the above parameters to prepare the Device Trigger Request (DTR) and ensures that the DCS (Data Coding Scheme) is set appropriately if not provided in the request.

[0090] At 404, after preparing the DTR, the eloT (SCEF / NEF + MTC-IWF) (308) forwards the DTR to the Short Message Service Center (SMSC) (310) over a diameter protocol. The DTR includes additional technical details needed to complete the delivery to the loT device:• User Identifier and SM RP SME Address• Payload• Device Payload Format (DCS)• Serving Node Identity and Additional Serving Node Identity• Trigger Reference Number and Old Trigger Reference Number• Validity Time• Priority Indication• SMS Application Port ID• Supported Features and Trigg er- Action

[0091] The SMSC (310) uses these details to initiate the trigger and prepare it for transmission to the loT device (312).

[0092] At step 406, after processing the DTR, the SMSC (310) sends a device trigger answer diameter back to the SCEF (308). The DTA is a response indicates the outcome of the trigger initiation, such as success or failure, and includes any relevant status information.

[0093] At step 408, once the SMSC (310) attempts delivery to the loT device (312), the SMSC (310) generates a delivery report request over the diameter protocol, providing the eloT (SCEF / NEF + MTC-IWF) (308) with a status update regarding the delivery. This includes whether the trigger reached the loT device (312) successfully or if there were issues.

[0094] At 410, the eloT (SCEF / NEF + MTC-IWF) (308) then responds with a delivery report answer of the diameter protocol, confirming receipt of the delivery status information.

[0095] At 412, the eloT (SCEF / NEF + MTC-IWF) (308) sends a trigger submit confirmation back to the SCS / AS / AF (302) over the HTTP. This message serves as an acknowledgment that the trigger request was successfully processed and forwarded to the SMSC (310).

[0096] At 414, a trigger delivery report is sent from the eloT (SCEF / NEF + MTC-IWF) (308) to the SCS / AS / AF (302) over the HTTP, providing the final delivery status of the trigger request.

[0097] At 416, the SCS / AS / AF (302) responds with a trigger delivery response over the HTTP, completing the transaction. The exchange allows the SCS / AS / AF (302) toreceive confirmation on the outcome of the device trigger and take any necessary follow-up actions.

[0098] FIG. 5 illustrates another exemplary flow diagram of a method (500) for delivering the trigger request to the device in the network (106), in accordance with an embodiment of the present disclosure. The flow diagram outlines the process for handling device trigger requests received from the SCS / AS / AF (Service Capability Server / Application Server / Application Function) (302) and determining the appropriate payload format to forward the request to the SMSC (Short Message Service Center) (310) for delivery to the Internet of Things (loT) device (312). FIG. 5 is explained in conjunction with the FIGs. 1, 2, 3, and 4.

[0099] At 502, the process starts when the eloT (Service Capability Exposure Function (SCEF) / Network Exposure Function (NEF) + Machine Type Communication-Interworking Function (MTC-IWF)) (308) receives the Device Trigger Request (DTR) from the SCS / AS / AF (302). This request typically includes parameters, such as the device identifier and trigger payload, which specify the message and instructions for the SMSC (310) to communicate with the loT device (312).

[0100] At 504, after receiving the DTR, the next step is to check whether a specific payload format has been included in the request. The payload format, typically indicated by the Data Coding Scheme (DCS), defines how the trigger message should be encoded and interpreted by the receiving device.

[0101] At 506, once the payload format is determined (either from the request or the pre-configured setting), the Cellular Internet of Things (eloT) (SCEF / NEF + MTC-IWF) (308) submits the device trigger to the SMSC (310) along with the selected payload format. The SMSC (310) then uses this information to encode and send the message to the loT device (312).

[0102] At 508, if the payload format is not explicitly specified in the request, the system defaults to using the payload format configured during the initial provisioning of the SCS / AS / AF (302), ensuring consistency in the message format if the SCS / AS / AF did not define a specific format for the request. The payload format is fetched for SCS / AS / AF (302).

[0103] FIG. 6 illustrates another exemplary flow diagram of a method (600) for delivering the trigger request to the device in the network (106), in accordance with an embodiment of the present disclosure. FIG. 6 is explained in conjunction with the FIGs. 1, 2, 3, 4, and 5.

[0104] At step 602, the trigger request is received from a node by a first network function. The first network function includes at least one of a Service Capability Exposure Function (SCEF), a Network Exposure Function (NEF), or a Machine Type Communication-Interworking Function (MTC-IWF). In an exemplary embodiment, a utility company runs an Application Server (AS) that manages smart electricity meters. When the company wants to pull a consumption log from a particular meter, the AS sends an HTTP / REST or Diameter-based Device Trigger Request (DTR) towards the operator’s SCEF (first NF). The DTR carries at least the device identifier (e.g., MSISDN or external ID), the trigger payload (e.g., “SEND_METER_READING”), and optional metadata such as priority and validity time.

[0105] At step 604, whether the trigger request includes a header corresponding to a device payload format is determined. In the exemplary embodiment, the SCEF parses the incoming trigger request and inspects the message headers or information elements, for example, an HTTP header named devicePay loadFormat or an equivalent Diameter A VP. If the first network function finds devicePayloadFormat, BINARY, it concludes that the AS is explicitly telling the network that the payload is binary. If no such header is present, the first network function concludes that the DTR does not include an explicit device payload format indication.

[0106] Upon the determining that the trigger request includes the header, at step 606, an Information Element (IE) associated with a Data coding Scheme (DCS) corresponding to a payload format is added to the trigger request. In the exemplary embodiment, from devicePayloadFormat, BINARY, the SCEF looks up a mapping table configured by the operator, such as BINARY — DCS = 0xF5 (example value), TEXT GSM7 DCS = 0x00, and UCS2 DCS = 0x08, etc. The SCEF selects DCS = 0xF5 and constructs a new Information Element (IE), for example a Diameter AVP DCS-Indicator, whose value is 0xF5. The IE is then inserted into the internal representation of the trigger request so that downstream nodes know exactly which DCS to use.

[0107] At step 608, the trigger request is transmitted along with the added IE to a second network function over a T4 interface. The second network function includes a Short Message Service Centre (SMSC). In the exemplary embodiment, the SCEF encodes the enriched DTR into a T4 (e.g., Diameter-based) message addressed to the operator’s SMSC. The message contains the device identifier, trigger payload, and the newly added DCS-Indicator IE with value 0xF5. The T4 message is then routed over a secure transport (e.g., SCTP / TLS) to the SMSC.

[0108] At step 610, the received trigger request is encoded based on the DCS. In the exemplary embodiment, the SMSC reads the DCS-Indicator IE (0xF5) from the T4 message, constructs an SMS TPDU for the target smart meter, places the trigger payload into the User Data field, treating it as binary because the DCS says so, and sets the TPDU’s DCS field to 0xF5, aligning the payload encoding and the DCS. If the payload is too long, the SMSC may segment it into multiple concatenated SMS messages with proper UDH, all using the same DCS.

[0109] At step 612, the encoded trigger request is transmitted to the device. In the exemplary embodiment, the SMSC forwards the encoded SMS trigger into the mobile network (e.g., via MSC / SGSN / MME / AMF and gNB / NodeB). The smart meterreceives the SMS, reads the DCS (OxF5), interprets the payload as binary, and correctly parses the “SEND METER READING” command. The meter then initiates a data session back to the AS to send the requested reading.

[0110] Upon determining that the trigger request does not include the header, a predefined DCS is retrieved based on one or more configurations associated with the node. The one or more configurations are provided by a user at a time of provisioning of the node, and the node includes one of a Services Capability Server (SCS), an Application Server (AS), and an Application Function (AF). The trigger request is enriched with the retrieved predefined DCS. Further, the enriched trigger request is transmitted to the second network function. In the exemplary embodiment, during provisioning of the AS / SCS / AF, the operator configures a default DCS per node (and optionally per service). For a DTR from this AS without devicePayloadFormat, the SCEF identifies the AS (e.g., via client ID / realm) and fetches the Default DCS = 0x00 from its configuration database. The SCEF creates the same DCS-Indicator IE but this time with value 0x00 (predefined). The IE is inserted into the trigger request exactly as in the “header present” case. The enriched DTR, now carrying DCS-Indicator = 0x00, is sent over T4 to the SMSC. Further, the SMSC again encodes the SMS trigger using DCS 0x00 (GSM 7-bit) and delivers the SMS to the device.

[0111] In an embodiment, the present disclosure is implemented in a network supporting the Diameter-based T4 interface between the MTC-IWF and the SMS-SC, where “the T4 interface allows transfer of device trigger from MTC-IWF to SMS-SC inside HPLMN domain, along with the serving SGSN / MME / MSC / SMSF identities, and allows SMS-SC to report to MTC-IWF the submission outcome of a device trigger and the success or failure of delivering the device trigger to the UE.” In the embodiment, the first network function of the present disclosure corresponds to the MTC-IWF / SCEF / NEF, and the second network function corresponds to the SMS-SC / SMSC. The present disclosure aligns with the Device Trigger Procedure, where “the procedure shall be used between the MTC-IWF and the SMS-SC for devicetrigger. The procedure shall be invoked by the MTC-IWF and is used to transfer device trigger to SMS-SC inside HPLMN domain to transfer to the SMS-SC the identities of the serving MSC or MME but not both, and / or SGSN, and / or SMSF, and / or IP-SM-GW serving the user for SMS along with device trigger to transfer device trigger replace / recall message to SMS-SC inside HPLMN domain. The procedure is mapped to the commands Device-Trigger-Request / Answer in the Diameter application.” In particular, the present disclosure reuses the standard Device-Trigger-Request (DTR) command, where “the Device-Trigger-Request (DTR) command, indicated by the Command-Code field set to 8388643 and the ‘R’ bit set in the Command Flags field, is sent from the MTC-IWF to the SMS-SC.

[0112] FIG. 7 illustrates an exemplary computer system (700) in which or with which embodiments of the present disclosure may be implemented.

[0113] As shown in FIG. 7, the computer system (700) may include an external storage device (710), a bus (720), a main memory (730), a read-only memory (740), a mass storage device (750), a communication port (760), and a processor (770). A person skilled in the art will appreciate that the computer system (700) may include more than one processor (770) and communication ports (760). The processor (770) may include various modules associated with embodiments of the present disclosure.

[0114] In an embodiment, the communication port (760) may be any of an RS-232 port for use with a modem-based dialup connection, a 10 / 100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fibre, a serial port, a parallel port, or other existing or future ports. The communication port (760) may be chosen depending on the network (106), such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system (700) connects.

[0115] In an embodiment, the memory (730) may be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. Read-only memory (740) may be any static storage device(s) e.g., but not limited to, a Programmable ReadOnly Memory (PROM) chips for storing static information e.g., start-up or Basic Input / Output System (BIOS) instructions for the processor (770).

[0116] In an embodiment, the mass storage device (750) may be any current or future mass storage solution, which may be used to store information and / or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and / or Firewire interfaces), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g., an array of disks (e.g., SATA arrays).

[0117] In an embodiment, the bus (720) communicatively couples the processor(s) (770) with the other memory, storage, and communication blocks. The bus (720) may be, e.g., a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB) or the like, for connecting expansion cards, drives and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor (770) to the computer system (700).

[0118] In an embodiment, a method for delivering a trigger request to a device in a network is described. The method includes receiving the trigger request from a node. The method includes determining whether the trigger request includes a header corresponding to a device pay load format. Upon the determining that the trigger request includes the header, the method further include adding an Information Element (IE) associated with a Data coding Scheme (DCS) corresponding to a payload format to the trigger request. Further, the method includes transmitting the trigger request along with the added IE to a second network function over a T4 interface. The method includes encoding the received trigger request based on the DCS. The method includes transmitting the encoded trigger request to the device.

[0119] In another exemplary embodiment, a system for delivering a trigger request to a device in a network is described. The system includes a first network function configured to receive the trigger request from a node. Further, the first network function is configured to determine whether the trigger request includes a header corresponding to a device pay load format. If the trigger request includes the header, the first network function is configured to add an Information Element (IE) associated with a Data coding Scheme (DCS) corresponding to a payload format to the trigger request. The first network function is configured to transmit the trigger request along with the added IE to a second network function over a T4 interface. Further, the system includes the second network function configured to encode the received trigger request based on the DCS. The second network function is configured to transmit the encoded trigger request to the device.

[0120] The table below represents the device trigger procedure sequence with request parameters:

[0121] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.

[0122] The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.

[0123] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be implemented merely as illustrative of the disclosure and not as a limitation.TECHNICAL ADVANTAGES

[0124] The present disclosure, as described above, offers several significant technical advantages that enhance the functionality and efficiency of the network, including, but not limited to:

[0125] Explicit end-to-end DCS signaling: The disclosure enables the first network function (SCEF / NEF / MTC-IWF) to insert an explicit Information Element (IE) carrying a Data Coding Scheme (DCS) into the trigger request, so the SMSC no longer has to guess the encoding and can deterministically apply the correct DCS for each device trigger.

[0126] Header-based payload format mapping: When a device payload format header (e.g. devicePayloadFormat) is present in the trigger request, the first network function maps this header to a corresponding DCS value using configurable profiles, allowing fine-grained support for multiple text and binary formats across heterogeneous loT applications.

[0127] Fallback using provisioned default DCS: When the pay load format header is absent, the first network function retrieves a predefined DCS from node-specific provisioning (per SCS / AS / AF), ensuring that even legacy or non-upgraded applications still benefit from a consistent DCS indication without requiring changes in those nodes.

[0128] Improved reliability of device trigger delivery: By ensuring that every trigger request reaching the SMSC carries an explicit or default DCS, the probability of misencoded SMS payloads, corrupted triggers, and decoding failures at the device is significantly reduced, thereby improving success rate and robustness of M2M / IoT device triggering.

[0129] Scalable support for diverse services and payloads: Centralizing DCS mapping and defaults in the SCEF / NEF / MTC-IWF allows operators to on-board new loT services and payload formats (e.g. new binary protocols, UCS2 content) through configuration, without per-service SMSC logic or hard-coded assumptions, which simplifies network evolution and scaling.

[0130] Compatibility with existing T4 procedures: The present disclosure enriches existing T4-based device trigger signaling by adding a new DCS-related IE / AVP while keeping all standard IES intact, so it can be deployed without changing the standardized device trigger procedure and remains backward compatible with SMSCs or applications that do not yet use the payload-format header.

Claims

ClaimsWhat is claimed is:

1. A method (600) for delivering a trigger request to a device in a network (106), the method (600) comprising:receiving (602), by a first network function (208), the trigger request from a node;determining (604), by the first network function (208), whether the trigger request comprises a header corresponding to a device payload format;upon the determining that the trigger request comprises the header, adding (606), by the first network function (208), an Information Element (IE) associated with a Data coding Scheme (DCS) corresponding to a payload format to the trigger request;transmitting (608), by the first network function (208), the trigger request along with the added IE to a second network function (212) over a T4 interface;encoding (610), by the second network function (212), the received trigger request based on the DCS; andtransmitting (612), by the second network function (212), the encoded trigger request to the device.

2. The method (600) as claimed in claim 1 , wherein the first network function (208) comprises at least one of a Service Capability Exposure Function (SCEF), a Network Exposure Function (NEF), or a Machine Type Communication-Interworking Function (MTC-IWF).

3. The method (600) as claimed in claim 1, wherein the second network function (212) comprises a Short Message Service Centre (SMSC).

4. The method (600) as claimed in claim 1, wherein the DCS is an Attribute Value Pair (A VP) contained in the header associated with the device payload format.

5. The method (600) as claimed in claim 1, wherein upon determining that the trigger request does not comprise the header, the method (600) comprising:retrieving, by the first network function (208), a predefined DCS based on one or more configurations associated with the node, wherein the one or more configurations are provided by a user at a time of provisioning of the node, and wherein the node comprises one of a Services Capability Server (SCS), an Application Server (AS), and an Application Function (AF);enriching, by the first network function (208), the trigger request with the retrieved predefined DCS; andtransmitting, by the first network function (208), the enriched trigger request to the second network function (212).

6. A system (108) for delivering a trigger request to a device in a network (106), the system (108) comprising:a first network function (208) configured to:receive the trigger request from a node;determine whether the trigger request comprises a header corresponding to a device payload format;if the trigger request comprises the header, add an Information Element (IE) associated with a Data coding Scheme (DCS) corresponding to a payload format to the trigger request; andtransmit the trigger request along with the added IE to a second network function over a T4 interface; andthe second network function (212) configured to:encode the received trigger request based on the DCS; andtransmit the encoded trigger request to the device.

7. The system (108) as claimed in claim 6, wherein the first network function (208) comprises at least one of a Service Capability Exposure Function (SCEF), a Network Exposure Function (NEF), or a Machine Type Communication-Interworking Function (MTC-IWF).

8. The system (108) as claimed in claim 6, wherein the second network function (212) comprises a Short Message Service Centre (SMSC).

9. The system (108) as claimed in claim 6, wherein the DCS is an Attribute Value Pair (A VP) contained in the header associated with a device payload format.

10. The system (108) as claimed in claim 6, wherein if the trigger request does not comprise the header, the first network function (208) is configured to:retrieve a predefined DCS based on one or more configurations associated with the node, wherein the one or more configurations are provided by a user at a time of provisioning of the node, and wherein the node comprises one of a Services Capability Server (SCS), an Application Server (AS), and an Application Function (AF);enrich the trigger request with the retrieved predefined DCS; andtransmit the enriched trigger request to the second network function.

11. A user equipment (UE) (104) communicatively coupled with a network (106), the coupling comprises steps of:receiving, by the network (106), a connection request from the UE (104);sending, by the network (106), an acknowledgment of the connection request e UE (104); andtransmitting a plurality of signals in response to the connection request, wherein a trigger request is received by the UE (104) in the network (106) by a method (600) as claimed in claim 1.

Images