DESC:RESERVATION OF RIGHTS
[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and/or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.

FIELD OF DISCLOSURE
[0002] The embodiments of the present disclosure generally relate to an advanced metering infrastructure. In particular, the present disclosure relates to an edge computing enabled intelligent push architecture for smart meters.

BACKGROUND OF DISCLOSURE
[0003] 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.
[0004] Advanced Metering Infrastructure (AMI) provides for gathering and transfer of energy usage information in near real-time. AMI is commonly used by the Water, Gas, and Electric distribution companies to obtain the necessary information to improve energy efficiency and derive other operational benefits for managing costs and improving customer service. AMI includes a smart meter, a bidirectional communication network, and a headend system (HES) acting as a control centre. Communication network is an important component of AMI and is driven by the need for low-cost, low-bandwidth, and delay-insensitive metering.
[0005] Most of the AMI solution systems deploy communication of device language message specification (DLMS) messages from the smart meter to the HES over transmission control protocol (TCP). HES includes schedulers to pull or fetch data from the smart meters. Each DLMS message is at the lowest level of meter hardware known as a “register” (identified by Object Identification System ‘OBIS’ code which is a unique identification of the registers in the meter’s memory). So, a high-level instruction such as “Read Meter Usage Data” may be de-constructed into 10, 20, or even more, low-level DLMS messages, each one with a send or acknowledgement TCP protocol overhead. Due to this low-level, connection-oriented style of communication, the amount of two-way data exchanged, and the time taken by a single meter read is significantly high and requires a communication network with wider bandwidths.
[0006] The recent advancement in the AMI considers narrow band communication networks such as, narrow band internet of things (NB-IoT). NB-IoT has relatively lower bandwidth and lesser data rates, and hence, is prone to communication failure for meters having heavier profiles. The existing DLMS protocol as well as the way of getting the data from the meters is not suited for scalable transmission over NB-IoT network.
[0007] There is, therefore, a need in the art to provide an AMI architecture that can overcome the shortcomings of the existing prior arts.

OBJECTS OF THE PRESENT DISCLOSURE
[0008] Some of the objects of the present disclosure, which at least one embodiment herein satisfies are as listed herein below.
[0009] It is an object of the present disclosure to provide an edge computing enabled intelligent push architecture to minimize the usage of network resources, bandwidth, and data consumption.
[0010] It is another object of the present disclosure to provide an architecture that may function both as a standalone or a hybrid architecture.
[0011] It is another object of the present disclosure to provide a method where a headend system (HES) may configure scheduled reading on a communication module associated with a smart meter as a part of meter commissioning process.
[0012] It is another object of the present disclosure to provide a method for the communication module to read low-level device language messaging specification (DLMS) messages with the smart meter over a serial port.
[0013] It is another object of the present disclosure to provide a method for the communication module to reconstruct the low-level DLMS messages to generate a single high-level message in a format compatible for the HES.
[0014] It is yet another object of the present disclosure to provide a method for the communication module to push the reconstructed message to the HES over a communications network.
[0015] It is yet another object of the present disclosure to provide a method for the communication module to detect failure at various stages of a Pull command from the HES and initiate an “Intelligent Push” mechanism locally through edge computing.

SUMMARY
[0016] In an aspect, the present disclosure relates to a system for communicating device language message specification (DLMS) messages. The system includes a communication module, one or more processors, and a memory operatively coupled to the one or more processors, wherein the memory includes processor-executable instructions, which on execution, cause the one or more processors to receive a configuration message associated with the communication module from a headend system (HES), direct the communication module to read one or more DLMS messages associated with a smart meter based on the configuration message, and push the read one or more DLMS messages to the HES.
[0017] In some embodiments, the configuration message includes scheduling information associated with the reading of the one or more DLMS messages, wherein the one or more DLMS messages include low-level messages.
[0018] In some embodiments, the one or more processors are configured to reconstruct the one or more DLMS messages to a high-level message and push the reconstructed high-level message to the HES.
[0019] In some embodiments, the one or more processors are configured to receive a command from the HES for sending the one or more DLMS messages to the HES, detect a failure associated with receiving the command from the HES, and push the one or more DLMS messages to the HES based on the detected failure. In some embodiments, the one or more processors are configured to push a DLMS message of the one or more DLMS messages available at a particular time instance based on the detection of the failure associated with receiving the command from the HES, and push a reconciled DLMS message during a pre-configured time based on the detection of the failure prior to receiving the command from the HES.
[0020] In another aspect, the present disclosure relates to a method for communicating DLMS messages. The method includes receiving, by one or more processors, a configuration message associated with a communication module from an HES, wherein the configuration message includes scheduling information associated with the reading of one or more DLMS messages, directing, by the one or more processors, the communication module to read one or more DLMS messages associated with a smart meter based on the configuration message, and pushing, by the one or more processors, the read one or more DLMS messages to the HES, wherein the one or more DLMS messages include low-level messages.
[0021] In some embodiments, the method includes reconstructing, by the one or more processors, the one or more DLMS messages to a high-level message and pushing, by the one or more processors, the reconstructed high-level message to the HES.
[0022] In some embodiments, the method includes receiving, by the one or more processors, a command from the HES for sending the one or more DLMS messages to the HES, detecting, by the one or more processors, a failure associated with receiving the command from the HES, and pushing, by the one or more processors, the one or more DLMS messages to the HES based on the detected failure. In some embodiments, the method includes pushing, by the one or more processors, a DLMS message of the one or more DLMS messages available at a particular time instance based on detecting the failure associated with receiving the command from the HES and a reconciled DLMS message during a pre-configured time based on detecting the failure prior to receiving the command from the HES.
[0023] In another aspect, the present disclosure relates to a user equipment (UE) for communicating DLMS messages. The UE includes one or more processors and a memory operatively coupled to the one or more processors, wherein the memory includes processor-executable instructions, which when executed by the one or more processors, cause the one or more processors to receive a configuration message associated with a communication module from an HES, direct the communication module to read one or more DLMS messages associated with a smart meter based on the configuration message, and push the read one or more DLMS messages to the HES.

BRIEF DESCRIPTION OF DRAWINGS
[0024] 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 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 the disclosure of electrical components, electronic components or circuitry commonly used to implement such components.
[0025] FIG. 1 illustrates an exemplary network architecture (100) in which or with which a proposed system may be implemented, in accordance with embodiments of the present disclosure.
[0026] FIG. 2 illustrates an exemplary block diagram representation (200) of an advanced metering infrastructure (AMI), in accordance with embodiments of the present disclosure.
[0027] FIG. 3 illustrates an exemplary block diagram (300) of the proposed system for device language messaging specification (DLMS) message communication, in accordance with an embodiment of the present disclosure.
[0028] FIG. 4 illustrates a conventional message flow diagram (400).
[0029] FIG. 5 illustrates an exemplary message sequence flow diagram (500) associated with a standalone mode of the AMI, in accordance with embodiments of the present disclosure.
[0030] FIG. 6 illustrates an exemplary flow chart of a method (600) associated with a hybrid operation mode of the AMI, in accordance with embodiments of the present disclosure.
[0031] FIG. 7 illustrates an exemplary computer system (700) in which or with which embodiments of the present disclosure may be implemented.
[0032] The foregoing shall be more apparent from the following more detailed description of the disclosure.

DETAILED DESCRIPTION OF DISCLOSURE
[0033] 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 all 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.
[0034] 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 and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.
[0035] 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.
[0036] Also, it is noted that individual embodiments may be described as a process which 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.
[0037] 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, such terms are intended to be inclusive—in a manner similar to the term “comprising” as an open transition word—without precluding any additional or other elements.
[0038] 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.
[0039] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly 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 and all combinations of one or more of the associated listed items.
[0040] Certain terms and phrases have been used throughout the disclosure and will have the following meanings in the context of the ongoing disclosure.
[0041] The term “Internet of Things” may refer to a computing environment in which physical objects are embedded with devices which enable the physical objects to achieve greater value and service by exchanging data with other systems and/or other connected devices. Each physical object is uniquely identifiable through its embedded device(s) and is able to interoperate within an Internet infrastructure. The acronym “IoT,” as used herein, means “Internet of Things.”
[0042] The term “AMI” may refer to advanced metering infrastructure composed of consumption meters, a two-way communication channel, and a data repository or headend system (HES).
[0043] The term “smart meter” may refer to an electronic device capable of recording information such as consumption of electric energy, voltage levels, current, and power factor, and provide the same to the energy supplier through a remote connection.
[0044] The term “DLMS” may refer to device language messaging specification providing an interoperable environment for structured modelling and meter data exchange.
[0045] The term “low-level message” may refer to the hardware level DLMS messages.
[0046] The term “high-level message” may refer to message compatible with transmission control protocol (TCP) format.
[0047] The term “real time” may refer to a level of processing responsiveness that a user or system senses as sufficiently immediate for a particular process or determination to be made, or that enables a processor to keep up with some external process.
[0048] The various embodiments throughout the disclosure will be explained in more detail with reference to FIGs. 1-7.
[0049] FIG. 1 illustrates an exemplary network architecture (100) in which or with which embodiments of the present disclosure may be implemented.
[0050] Referring to FIG. 1, the network architecture (100) may include one or more computing devices (104-1, 104-2…104-N) associated with one or more users (102-1, 102-2…102-N) deployed in an environment. In some embodiments, the network architecture (100) may be an advanced metering infrastructure (AMI). A person of ordinary skill in the art will understand that one or more users (102-1, 102-2…102-N) may be individually referred to as the user (102) and collectively referred to as the users (102). Further, a person of ordinary skill in the art will understand that one or more computing devices (104-1, 104-2…104-N) may be individually referred to as the computing device (104) and collectively referred to as the computing devices (104).
[0051] In an embodiment, each computing device (104) may interoperate with every other computing device (104) in the network architecture (100). In an embodiment, the computing devices (104) may be referred to as a user equipment (UE). A person of ordinary skill in the art will appreciate that the terms “computing device(s)” and “UE” may be used interchangeably throughout the disclosure.
[0052] In an embodiment, the computing devices (104) may include, but are not limited to, a handheld wireless communication device (e.g., a mobile phone, a smart phone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted 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 (104) with wireless communication capabilities, and the like. In an embodiment, the computing devices (104) may include, but are not limited to, any electrical, electronic, electro-mechanical, or an 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 computing device (104) may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as camera, audio aid, a microphone, a keyboard, and input devices for receiving input from a user (102) such as touch pad, touch enabled screen, electronic pen, and the like.
[0053] In an embodiment, the computing devices (104) may include smart devices operating in a smart environment, for example, the IoT system. In such an embodiment, the computing devices (104) may include, but are not limited to, smart phones, smart watches, smart sensors (e.g., mechanical, thermal, electrical, magnetic, etc.), smart meters, networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, smart accessories, tablets, smart television (TV), computers, smart security system, smart home system, other devices for monitoring or interacting with or for users (102) and/or places, or any combination thereof. In an embodiment, the computing devices (104) may include one or more of the following components: sensor, radio frequency identification (RFID) technology, GPS technology, mechanisms for real-time acquisition of data, passive or interactive interface, mechanisms of outputting and/or inputting sound, light, heat, electricity, mechanical force, chemical presence, biological presence, location, time, identity, other information, or any combination thereof.
[0054] A person of ordinary skill in the art will appreciate that the computing devices (104) may include, but not be limited by, intelligent, multi-sensing, network-connected devices, that can integrate seamlessly with each other and/or with a central server or a cloud-computing system or any other device that is network-connected.
[0055] A person of ordinary skill in the art will appreciate that the computing devices or UEs (104) may not be restricted to the mentioned devices and various other devices may be used.
[0056] Referring to FIG. 1, the computing devices (104) may communicate with a head end system (HES) (108) of the AMI (100) through a network (106). In an embodiment, the network (106) may include at least one of a Fourth Generation (4G) network, a Fifth Generation (5G) network, or the like. The network (106) may enable the computing devices (104) to communicate between devices (104) and/or with the HES (108). As such, the network (106) may enable the computing devices (104) to communicate with other computing devices (104) via a wired or wireless network. The network (106) may include a wireless card or some other transceiver connection to facilitate this communication. In an exemplary embodiment, the network (106) may incorporate one or more of a plurality of standard or proprietary protocols including, but not limited to, Wi-Fi, ZigBee, or the like. In another embodiment, the network (106) may be implemented as, or include, any of a variety of different communication technologies such as a low power wide area network (LPWAN) such as, without limitations, a narrow band IoT (NB-IoT) or a long-term evolution machine type communication (CAT-M) network. In some other embodiments, the network (106) may include 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.
[0057] In an embodiment, the HES (108) may extract the captured data from the computing devices (104) to understand the amount of energy consumed by a particular user (102) and bill or charge the user accordingly. In some embodiments, the HES (108) is present in the premises of an energy supplier or may be a cloud-based platform for data collection and recording.
[0058] 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).
[0059] FIG. 2 illustrates an exemplary block diagram representation of an AMI (200), in accordance with embodiments of the present disclosure.
[0060] In an embodiment, the AMI (200) may include a computing device (104) for example, without limitations, an NB-IoT device in communication with an HES (108) through a communication network (106) such as, without limitations, LPWAN. The LPWAN may include, for example, without limitations, NB-IoT network or CAT-M network. NB-IoT has the advantage of being a cost-effective network, suited for limited mobility solution and for a better inbuilding network penetration.
[0061] Referring to FIG. 2, the computing device (104) may include a meter (202), for example, a smart meter connected to a system (210). The system (210) may include a universal subscriber identity module (USIM) (204) and a network interface card (NIC) or a communication module (220). The USIM (204) may be used by the computing device (104) to connect to any network through a communication port such as an antenna. The NIC (220) may include one or more communication layers for communicating with the HES (108). In an example embodiment, the communication layers may include an application layer (206), a transmission control protocol (TCP)/internet protocol (IP) layer (208), and a physical layer (212) comprising a modem and a modem client. The application layer (206) may include an embedded DLMS application. In an embodiment, the TCP layer (208) may reconstruct device-level messages or low-level messages received from the physical layer (212) to a high-level message for communicating with the HES (108). Further, the modem and the modem client of the physical layer (212) may assist in modulation and demodulation of signals for transmission to the HES (108) through the communication network (106).
[0062] Referring to FIG. 2, the NIC (220) may perform a scheduled reading from the meter (202) through a serial bus, for example, a universal asynchronous receiver transmitter (UART). In an example embodiment, the NIC (220) may read one or more low-level messages, for example, DLMS messages, from the meter (202) based on a command received from the HES (108). The NIC (220) may be configured by the HES (220) during a commissioning of the meter (202) to read the low-level messages associated with the meter (202). In one example embodiment, the message may include, but not be limited to, voltage, current, impedance variance, and temperature associated with the consumption by one or more appliances deployed in a user premise. In another example embodiment, the message may include, but not be limited to, an amount of gas or an amount of water consumed by a user (e.g., 102).
[0063] Referring to FIG. 2, the HES (108) may include communication layers similar to the communication layers present in the computing device (104). For example, the communication layers in the HES (108) may include an application layer (218), a TCP/IP layer (216), and a physical layer (214). The HES (108) may configure the system (210) during the commission of the meter (202). The configuration message may include a reading schedule for reading the DLMS messages from the meter (202). The system (210) may perform the reading based on the reading schedule and push the read DLMS messages to the HES (108). The HES (108) may use the DLMS message for various analysis such as, but not limited to, billing, analyzing usage pattern, etc.
[0064] In some embodiments, the AMI (200) may operate in a stand-alone mode, wherein the computing device (104) may be configured to provide “PUSH” notifications related to meter reading to the HES (108). In some other embodiments, the AMI (200) may operate in a hybrid mode, wherein the computing device (104) may be configured to provide notification(s) related to meter readings based on a command, for example, a “meter profile read” command received from the HES (108) and in case of detecting any failure, the computing device (104) may send the meter readings as “PUSH” notifications to the HES (108).
[0065] A person of ordinary skill in the art will appreciate that the exemplary block diagram (200) may be modular and flexible to accommodate any kind of changes in the AMI.
[0066] FIG. 3 illustrates an exemplary block diagram (300) of the proposed system for DLMS message communication, in accordance with an embodiment of the present disclosure.
[0067] In particular, the system (210) may include one or more processor(s) (302). The one or more processor(s) (302) may be implemented as one or more microprocessors, microcomputers, microcontrollers, edge or fog microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) (302) may be configured to fetch and execute computer-readable instructions stored in a memory (304) of the system (210). The memory (304) 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 (304) may comprise any non-transitory storage device including, for example, volatile memory such as Random-Access Memory (RAM), or non-volatile memory such as Electrically Erasable Programmable Read-only Memory (EPROM), flash memory, and the like.
[0068] In an embodiment, the system (210) may include an interface(s) (306). The interface(s) (306) may comprise a variety of interfaces, for example, interfaces for data input and output devices, referred to as input/output (I/O) devices like a USIM interface (306-1), a UART interface (306-2), a modulation and demodulation (MODEM) interface (306-3), and interfaces for storage devices, and the like. The interface(s) (306) may facilitate communication for the system (210). The interface(s) (306) may also provide a communication pathway for one or more components of the system (210). Examples of such components include, but are not limited to, processing unit/engine(s) (308) and a database (316).
[0069] The processing unit/engine(s) (308) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing unit(s) (308). In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing unit(s) (308) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processing unit(s) (308) may comprise a processing resource (for example, one or more processors), 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 processing unit(s) (308). In such examples, the system (210) may include 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 (210) and the processing resource. In other examples, the processing unit(s) (308) may be implemented by electronic circuitry. In an aspect, the database (316) may comprise data that may be either stored or generated as a result of functionalities implemented by any of the components of the processor (302) or the processing engines (308).
[0070] In an embodiment, the processing unit (308) may include one or more units that may receive a configuration message from the HES (108) of FIG. 2 for performing a scheduled reading of the DLMS messages from the meter (202) of FIG. 2 to construct a high-level DLMS message. In an embodiment, information associated with the configuration message may be stored in the database (316). In another embodiment, the read DLMS messages may be stored in the database (316) for a certain time period. In an embodiment, the processing engine (308) may include one or more modules/units such as, but not limited to, an acquisition unit (310), a reconstruction unit (312), and an NIC unit (314). It may be appreciated that the NIC unit (314) may be similar to the NIC (220) of FIG. 2 in its functionality.
[0071] By way of example but not limitation, the one or more processor(s) (302) may obtain DLMS messages from the meter (202) to send it to the HES (108). Further, in an embodiment, the one or more processor(s) (302) may cause the acquisition unit (310) to obtain the DLMS messages read by the NIC unit (314) for further processing by the reconstruction unit (312). The reconstruction unit (312) may generate a single high-level message from one or more low-level DLMS messages. The high-level message may further be communicated to the HES (108) using the interface(s) (306).
[0072] A person of ordinary skill in the art will appreciate that the exemplary block diagram (300) may be modular and flexible to accommodate any kind of changes in the system (210). Although FIG. 3 shows exemplary components of the block diagram (300), in other embodiments, the block diagram (300) may include fewer units, different units, differently arranged units, or additional functional units than depicted in FIG. 3. Additionally, or alternatively, one or more units of the system (210) may perform functions described as being performed by one or more other units of the system (210).
[0073] FIG. 4 illustrates a conventional message sequence flow diagram (400). The messaging flow diagram (400) corresponds to the “PULL” messaging system employed in the AMI, wherein a lot of communication messages are involved between the computing device (104) and the HES (108) over a telecommunication service provider (TSP) network (106). The computing device (104) may include a smart meter (202) and a NIC or a communication module (220). In some embodiments, the communication module or the NIC (220) may perform a DLMS message reading from the meter (202) and may transfer the read messages to the HES (108).
[0074] Referring to FIG. 4, when a smart meter (202) is installed at a user site, a notification may be sent to the HES (108), wherein the notification may be sent through a meter data management system (MDMS) or a machine interface (MI) application. The HES (108), upon receiving the installation notification, may at step 410, initiate a command to the meter (202) to pull meter information through an on-demand schedule. The HES (108) may further at step 412, establish a three-way TCP handshake with the NIC (220). Upon successful handshake, the HES (108) may at step 414, send a DLMS application association request (AARQ) to the NIC (220) using a public client (PC client) and receive a DLMS application association response (AARE) from the NIC (220) in the PC client. The HES (108) may further at step 416, send a get innovation counter request to the NIC (220) in the PC client and receive, from the NIC (220), an innovation counter value as response on the PC client. The HES (108) may further at step 418, send a DLMS release request (RLRQ) to the NIC (220) in the PC client and receive, from the NIC (220) a DLMS release response in the PC client. Further, the HES (108) may at step 420, send a DLMS AARQ in a utility setting (US) client to the NIC (220) and receive, from the NIC (220), a DLMS AARE in the US client. The HES (108) may at step 422, send, to the NIC (220), a high level “Meter Profile read” request in the US client and receive, from the NIC (220), a response with acknowledgement.
[0075] Referring to FIG. 4, the HES (108) may at step 424, send, to the NIC (220), a get message request to read meter profile scalar values in US client and receive, from the NIC (220), a response with meter profile scalar value in the US client. Further, the HES (108) may at step 426, send, to the NIC (220), a get message request to read meter profile actual values in US client and receive, from the NIC (220), a response with meter profile actual value in the US client. Further, the HES (108) may at step 428, send, to the NIC (220), the DLMS RLRQ in US client and receive, from the NIC (220), the DLMS RLRE in the US client, followed by closing the TCP connection between the HES (108) and the NIC (220) at step 430.
[0076] Referring to the message flow illustrated in FIG. 4, it may be inferred that DLMS requires “connection-oriented” communication using TLS security and running over TCP. The existing AMI provides DLMS over TCP and includes schedulers for fetching data from the computing device (104) using “PULL” mechanism. In this connection-oriented style of communication, the amount of two-way data exchanged and the time taken by a single meter read is significantly high. This may lead to failure in the meter profile read in narrow band networks. Hence, a different technique for DLMS message communication is designed for narrow band networks and is discussed below in detail with reference to FIGs. 5 and 6.
[0077] FIG. 5 illustrates an exemplary message sequence flow diagram (500) associated with a standalone mode of the AMI, in accordance with some embodiments of the present disclosure.
[0078] In accordance with some embodiments, in a standalone mode of operation, the HES (108) may send a configuration message to the computing device (104) at the time of commissioning the smart meter (202). The configuration message may enable the communication module or the NIC (220) to periodically communicate with the smart meter (202) to obtain the readings, reconstruct the readings to a high-level message, and transmit or “PUSH” the reconstructed message to the HES (108). This process of transmitting or “PUSH” of only the high-level message may avoid more handshake messages or TCP overheads or acknowledgement messages through the TSP network (106).
[0079] Referring to FIG. 5, when a smart meter (202) is installed at a user site, a notification may be sent to the HES (108), wherein the notification may be sent through an MDMS or an MI application. The HES (108), at step 502, may receive an installation notification. Upon receiving the installation notification, the HES (108) may, at step 504, configure a PUSH schedule for the NIC (220) for performing scheduled meter readings, wherein the PUSH schedule may include configuring of various predefined schedules for different “Meter Profile read.” In some embodiments, the HES (108) may configure the PUSH over the TSP network (106) as a one-time activity.
[0080] Referring to FIG. 5, upon receiving the PUSH schedule configuration from the HES (108), the NIC (220) may, at step 506, save the schedules and act on the schedules based on an elapse of a scheduled time associated with a “Meter Profile read” locally. The NIC (220) may initiate a connection with the meter (202) over a serial port, for example, UART, and perform a set of low-level DLMS processes before requesting the actual “Meter Profile” from the meter (202). The low-level DLMS process may involve one or more of the following message exchanges between the NIC (220) and the meter (202).
[0081] Referring to FIG. 5, the NIC (220) may, at step 508, send a DLMS AARQ to the meter (202) in the PC client and receive a DLMS AARE from the meter (202) in the PC client. The NIC (220) may further, at step 510, send a get innovation counter request to the meter (202) in the PC client and receive, from the meter (202), an innovation counter value as response on the PC client. The NIC (220) may further, at step 512, send a DLMS RLRQ to the meter (202) in the PC client and receive, from the meter (202) a DLMS RLRE in the PC client. Further, the NIC (220) may, at step 514, send a DLMS AARQ in the US client to the meter (202) and receive, from the meter (202), a DLMS AARE in the US client.
[0082] Referring to FIG. 5, the NIC (220) may, at step 516, send, to the meter (202), a high level “Meter Profile read” request in the US client and receive, from the meter (202), a response with acknowledgement. Upon receiving the response for the “Meter Profile read” request, the NIC (220) may, at step 518, send, to the meter (202), a get message request to read meter profile scalar values in US client and receive, from the meter (202), a response with meter profile scalar value in the US client. Further, the NIC (220) may, at step 520, send, to the meter (202), a get message request to read meter profile actual values in US client and receive, from the meter (202), a response with meter profile actual value in the US client. Further, the NIC (220) may, at step 522, send, to the meter (202), the DLMS RLRQ in US client and receive, from the meter (202), the DLMS RLRE in the US client and thereby close the connection with the meter (202). Upon closing the connection with the meter (202), the NIC (220) may, at step 524, collect or consolidate the received meter profile data. In an embodiment, the collecting or consolidating of the received meter profile data may include reconstructing, by the NIC (220) the low-level DLMS messages read from the meter (202) into a high-level TCP message in a form compatible for reading by the HES (108). Further, the NIC (220) may, at step 526, establish a three-way TCP handshake with the HES (108). Upon successful establishment of the TCP connection with the HES (108), the NIC (220) may, at step 528, push the actual meter profile data to the HES (108) and receive an acknowledgement from the HES (108) for successful reception. The HES (108), at step 530, may use or consume the received meter data for its internal processing such as, billing, energy management, consumption analysis, etc. Referring to FIG. 5, upon receiving the acknowledgement from the HES (108), the NIC (220) may, at step 532, close the TCP connection with the HES (108).
[0083] FIG. 6 illustrates an exemplary flow chart of a method (600) associated with a hybrid operation mode of the AMI, in accordance with embodiments of the present disclosure.
[0084] In an embodiment, the hybrid operation mode or the hybrid model may co-exist with the conventional AMI with PULL mechanism and the NIC (220) may be configured to detect failures at multiple communication steps between the HES (108) and the computing device (104), and activate an edge computing based intelligent PUSH mechanism to PUSH the failed data based on the detected failure. In accordance with some embodiments, the hybrid operation may involve two paths: a happy path or a regular path, and an alternate path upon detecting failure in the regular path. By way of example, without limitations, the regular path or happy path may include messaging flow between the HES (108) and the NIC (220) similar to the messing flow between the HES (220) and the NIC (220) as discussed above with reference to FIG. 4.
[0085] Referring to FIG. 6, in an embodiment, the alternate path includes the NIC (202) detecting failures at multiple steps mentioned in the happy path or the regular path. In some embodiments, when the NIC (202) detects a failure before knowing what profile data the HES (104) was trying to fetch i.e., detects a failure before a “Meter Profile read” command is received from the HES (108), the NIC (220) may intelligently check what meter profile data was not sent due to failure detected at stages before receiving the command, locally get the meter profile data from the meter (202), and push it to the HES (108) at a pre-configured time. In some other embodiments, if the NIC (220) detects failure after receiving the “Meter Profile read” i.e., after knowing what profile data the HES (108) has tried to access, the NIC (220) may enable edge computing based intelligent push architecture, PULL locally the failed “meter profile” data, and PUSH it immediately to the HES (108).
[0086] Referring to FIG. 6, the method (600) describes the hybrid operation. The method may include, at step 602, initiating, at the HES (108), a command to PULL meter data from the meter (202), wherein the command may be initiated by a user operating the HES (108) or any official associated with an energy management company or an energy supplier. Further, the method (600) may include, at step 604, sending, by the HES (108), a TCP connection establishment request to the NIC (220) for establishing a connection with the meter (202). The method (600) may include, at step 606, determining, by the NIC (220), if the TCP connection is established. If the connection is established, the method (600) may include, at step 608, initiating, by the HES (108), a DLMS application association command in PC client at the application layer. On the other hand, if the TCP connection is not established, the method (600) may include, at step 634, landing in a state where NIC (220) is unaware of the “meter profile” the HES (108) was trying to fetch. The method (600) may include, at step 636, checking, by the NIC (220), a status associated with all meter profiles at a pre-configured fixed time. The method (600) may further include, at step 638, initiating, by the NIC (220), a local PULL command to the meter (202) to read the meter profile that was not sent during the detected failure. The method (600) may further include, at step 640, establishing a connection with the HES (108) to PUSH the meter profile data at a pre-defined time and closing the connection after receiving an acknowledgement for the pushed data, from the HES (108).
[0087] Referring to FIG. 6, upon initiating the DLMS application association command, the method (600) may include, at step 610, determining, by the NIC (202), whether the DLMS association is established in the PC client. If the DLMS association is established in the PC client, method (600) may include, at step 612, reading the invocation counter and releasing the DLMS association in the PC client. The method (600) may further include, at step 614, initiating the DLMS AARQ in US client. On the other hand, if the DLMS association is not established on the PC client, the NIC (220) performs steps 636-640 as discussed above.
[0088] Referring to FIG. 6, upon initiating the DLMS AARQ in the US client, the method (600) may include, at step 616, determining whether the DLMS association is established in the US client. If the DLMS association is not established in the US client, the NIC (220) may perform steps 636-640 as discussed above. On the other hand, if the DLMS association is established in the US client, the method (600) may include, at step 618, sending, by the HES (108) to the NIC (220), a high level “Meter Profile read” request in the US client and receiving, from the NIC (220), a response with acknowledgement. The method (600) may further include, at step 620, sending, by the HES (108) to the NIC (220), a get message request to read meter profile scalar values and receiving, from the NIC (220), a response with meter profile scalar value. Further, the method (600) may include, at step 622, sending, by the HES (108) to the NIC (220), a get message request to read meter profile actual values and receiving, from the NIC (220), a response with meter profile actual value. Further, the method (600) may include, at step 624, releasing the DLMS association between the HES (108) and NIC (220) in US client. The method (600) may further include, at step 626, closing the TCP connection between the HES (108) and the NIC (220).
[0089] In an embodiment, the NIC (220) may detect a failure during any of the steps 618-624 as discussed above and may perform one or more of the following actions. Referring to FIG. 6, the method (600) may include, at step 628, entering a state where the NIC (220) is unaware of the meter profile that was tried to fetch by the HES (108). The method may further include, at step 630, initiating, by the NIC (220), a local PULL command to the meter (202) immediately after detecting the failure to read the meter profile at any of the steps 618-624 and reading the meter profile at the same time duration as requested by the HES (108). The method (600) may further include, at step 640, establishing a connection with the HES (108) to PUSH the read meter profile data and closing the connection after receiving an acknowledgement for the pushed data, from the HES (108).
[0090] A person of ordinary skill in the art will appreciate that these are mere examples, and in no way, limit the scope of the present disclosure.
[0091] FIG. 7 illustrates an exemplary computer system (700) in which or with which embodiments of the present disclosure may be utilized. 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), communication port(s) (760), and a processor (770). A person skilled in the art will appreciate that the computer system (700) may include more than one processor and communication ports. The processor (770) may include various modules associated with embodiments of the present disclosure. The communication port(s) (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 fiber, a serial port, a parallel port, or other existing or future ports. The communication port(s) (760) may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system (700) connects. The main memory (730) may be random access memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory (740) may be any static storage device(s) including, but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or basic input/output system (BIOS) instructions for the processor (770). The mass storage device (750) may be any current or future mass storage solution, which may be used to store information and/or instructions.
[0092] The bus (720) communicatively couples the processor (770) with the other memory, storage, and communication blocks. The bus (720) can 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).
[0093] Optionally, operator and administrative interfaces, e.g. a display, keyboard, and a cursor control device, may also be coupled to the bus (720) to support direct operator interaction with the computer system (700). Other operator and administrative interfaces may be provided through network connections connected through the communication port(s) (760). In no way should the aforementioned exemplary computer system (700) limit the scope of the present disclosure.
[0094] 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 to be implemented merely as illustrative of the disclosure and not as limitation.

ADVANTAGES OF THE PRESENT DISCLOSURE
[0095] The present disclosure provides an improved success rate for transmitting heavier meter profiles from a smart meter to a headend system (HES) over narrow band telecom service provider (TSP) network.
[0096] The present disclosure provides energy consumption information to the HES which my use the information for devising strategy to save data consumption.
[0097] The present disclosure provides intelligent edge computing at the network interface card (NIC) to reduce the transmission of message overhead through the TSP network.
[0098] The present disclosure provides reduced messages for transmission over the TSP network and thereby reduces consumption of network resources.
,CLAIMS:1. A system (210) for communicating device language message specification (DLMS) messages, the system (210) comprising:
a communication module (220);
one or more processors (302); and
a memory (304) operatively coupled to the one or more processors (302), wherein the memory (304) comprises processor-executable instructions, which on execution, cause the one or more processors (302) to:
receive a configuration message associated with the communication module (220) from a headend system (HES) (108);
direct the communication module (220) to read one or more DLMS messages associated with a smart meter (202) based on the configuration message; and
push the read one or more DLMS messages to the HES (108).

2. The system (210) as claimed in claim 1, wherein the configuration message comprises scheduling information associated with the reading of the one or more DLMS messages.

3. The system (210) as claimed in claim 1, wherein the one or more DLMS messages comprise low-level messages.

4. The system (210) as claimed in claim 1, wherein the memory (304) comprises processor-executable instructions, which on execution, cause the one or more processors (302) to:
reconstruct the one or more DLMS messages to a high-level message; and
push the reconstructed high-level message to the HES (108).

5. The system (210) as claimed in claim 1, wherein the memory (304) comprises processor-executable instructions, which on execution, cause the one or more processors (302) to:
receive a command from the HES (108) for sending the one or more DLMS messages to the HES (108);
detect a failure associated with receiving the command from the HES (108); and
push the one or more DLMS messages to the HES (108) based on the detected failure.

6. The system (210) as claimed in claim 5, wherein the memory (304) comprises processor-executable instructions, which on execution, cause the one or more processors (302) to:
push a DLMS message of the one or more DLMS messages available at a particular time instance based on the detection of the failure associated with receiving the command from the HES (108).

7. The system (210) as claimed in claim 5, wherein the memory (304) comprises processor-executable instructions, which on execution, cause the one or more processors (302) to:
push a reconciled DLMS message during a pre-configured time based on the detection of the failure prior to receiving the command from the HES (108).

8. A method for communicating device language message specifications (DLMS) messages, the method comprising:
receiving, by one or more processors (302), a configuration message associated with a communication module (220) from a head end system (HES) (108);
directing, by the one or more processors (302), the communication module (220) to read one or more DLMS messages associated with a smart meter (202) based on the configuration message; and
pushing, by the one or more processors (302), the read one or more DLMS messages to the HES (108).

9. The method as claimed in claim 8, wherein the configuration message comprises scheduling information associated with the reading of the one or more DLMS messages.

10. The method as claimed in claim 8, wherein the one or more DLMS messages comprise low-level messages.

11. The method as claimed in claim 8, comprising:
reconstructing, by the one or more processors (302), the one or more DLMS messages to a high-level message; and
pushing, by the one or more processors (302), the reconstructed high-level message to the HES (108).

12. The method as claimed in claim 8, comprising:
receiving, by the one or more processors (302), a command from the HES (108) for sending the one or more DLMS messages to the HES (108);
detecting, by the one or more processors (302), a failure associated with receiving the command from the HES (108); and
pushing, by the one or more processors (302), the one or more DLMS messages to the HES (108) based on the detected failure.

13. The method as claimed in claim 12, comprising:
pushing, by the one or more processors (302), a DLMS message of the one or more DLMS messages available at a particular time instance based on detecting the failure associated with receiving the command from the HES (108).

14. The method as claimed in claim 12, comprising:
pushing, by the one or more processors (302), a reconciled DLMS message during a pre-configured time based on detecting the failure prior to receiving the command from the HES (108).

15. A user equipment (UE) for communicating device language message specifications (DLMS) messages, the UE comprising:
one or more processors; and
a memory operatively coupled to the one or more processors, wherein the memory comprises processor-executable instructions, which when executed by the one or more processors, cause the one or more processors to:
receive a configuration message associated with a communication module (220) from a headend system (HES) (108);
direct the communication module (220) to read one or more DLMS messages associated with a smart meter (202) based on the configuration message; and
push the read one or more DLMS messages to the HES (108).