US20200068354A1

US20200068354A1 - Sound Alarm Notification, System, Apparatus and Method

Info

Publication number: US20200068354A1
Application number: US16/667,862
Authority: US
Inventors: Scott Stapleford; Richard Shevelow
Original assignee: Pica Product Development LLC
Current assignee: Pica Product Development LLC
Priority date: 2017-11-07
Filing date: 2019-10-29
Publication date: 2020-02-27
Also published as: US11122394B2; US20200267509A1; US10694338B2; US20190200168A1

Abstract

An electronic device having a sound detection device and wireless transmission capability which detects sound, and in particular sound generated by a sound alarm, and sends a notification message to a remote notification service which alerts or otherwise notifies notification recipients that the sound alarm is sounding and/or has been triggered.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of U.S. application Ser. No. 16/183,732, filed Nov. 8, 2018, which claims the benefit of U.S. Provisional Application No. 62/582,508, filed Nov. 7, 2017; and further claims the benefit of U.S. Provisional Application No. 62/752,284, filed Oct. 29, 2018; each of which is hereby incorporated by reference in its entirety.

BACKGROUND OF THE INVENTION

Background

Alarm systems often generate a sound signal or vibration to alert people to the existence of an event or condition. For example, a smoke and/or carbon-monoxide detector typically generates a loud sound when it detects smoke and/or carbon-monoxide in the vicinity of the detector. Intrusion alarm systems often generate a loud sound upon detection of an intrusion to monitored premises. Emergency systems such as fire alarms and hazardous conditions alarms also generate loud sounds to alert people in the vicinity and to signal them to leave the area. Many other types of electronic systems and devices are designed to generate sound or vibrate to alert people nearby to the existence of a detected condition or occurrence of an event. For example, a battery powered smoke detector may monitor the charge level of the battery and upon detection of a low-battery condition, generate a sound (such as a short chirp, or a recorded or computer-generated voice that sounds a voice alert). As another example, a phone may ring or vibrate when a call is incoming.
Such systems generate sound/vibration for the purpose of alerting people to the existence of certain conditions. The importance to a person of receiving the alert may vary according to the use case for the sound-/vibration-generating device. For example, a sound/vibration alert from a life-safety monitoring system (such as a smoke or fire alarm) will typically be of very high importance, whereas a sound/vibration alert generated for mere information (such as, for example, a phone is receiving a phone call) may be of interest but may only be of high importance when an important phone call is expected. The importance of a sound alert may also be of interest or importance to be able to resolve the condition that triggered the sound/vibration alert. For example, if a carbon-monoxide alarm sounds, it is important to evacuate living people and animals from the premises and to remediate the unsafe condition.
When able people are present, a sound/vibration alert can save lives, prevent injury and/or inform, because the presence of an able person allows such person to receive the alert, process and/or act on the information associated with the sound/vibration alert. However, when a sound/vibrational alert is generated in an area where an able person is not present, damage and/or injury can occur. Incapacitated people, pets, other animals, plants/crops, or inanimate objects present in the affected area may not be able to respond in a way that a present and able person could. For example, a smoke detector may activate a loud unpleasant sound in a home occupied by household pets while the homeowner is away. Unless the smoke condition and a solution to remediating the source generating the condition are quickly resolved, the pets could be in danger. In another example, a smoke detector low battery condition may cause the smoke detector to generate a periodic “chirp”. In this situation, if there are pets in the home while the homeowner is away, while the pets are not in immediate danger, they may become uncomfortable being exposed to the incessant low-battery chirp of the smoke detector.
In view of the issues set forth above, a solution alerting able persons to the presence of a sound/vibration in an environment where an able person is not present is needed. Such solution would preferably be one that can be deployed without having to modify or replace existing infrastructure or equipment. Such solution would also preferably be one that could be deployed in remote locations that may not have access to an existing or reliable power source, and that could perform its function for potentially years without having to replace a battery or require additional maintenance. Such solution would also preferably be deployable in locations that do not have access to a local area network (LAN) or WiFi connection to the Internet. Such a solution would also preferably immediately notify one or more designated person(s) at their respective electronic device(s), of the alert condition. Presently, no such solution exists that meets all of the above needs.

BRIEF SUMMARY OF THE INVENTION

Solving the needs of the aforementioned problems, aspects of the present invention include systems, apparatuses, and methods for remotely monitoring an environment for sound signals. In an embodiment, the system remotely monitors an environment for a sound alarm signal generated by a sound alarm.
In an embodiment, a sound signal detection and alerting device includes an electronic sound detection device which generates one or more output signals in response to sound sensed from a sound signal generated by a sound alarm device. The sound signal detection and alerting device further includes a wireless transmitter configured to transmit data on an antenna, electronic memory which stores an identifier that is associated with both the electronic sound signal detection device and with a registered user of a notification service executing on a remote server, and a controller coupled to the sound detection device, the memory, and the wireless transmitter. In response to receiving the one or more output signals, the controller retrieves the identifier from memory, encodes the identifier into a notification message and transmits the notification message, via the transmitter, to the notification service.
The notification service receives the notification message, which triggers the notification service to send an electronic notification message to an electronic device associated with the identifier. The notification message notifies a user of the electronic device that the sound alarm device is sounding.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete appreciation of this invention, and many of its attendant advantages, will be readily apparent as the same becomes better understood by reference to the following detailed description when considered in conjunction with the accompanying drawings in which like reference symbols indicate the same or similar components, wherein:

FIG. 1 is a system diagram of an exemplary environment implementing a sound alarm notification system in accordance with an embodiment of the invention;

FIG. 2 is a flowchart illustrating an exemplary embodiment of a notification service method for notifying recipients of a detected sound alarm condition;

FIG. 3 is a network architecture diagram of an exemplary environment implementing a sound signal detection and alerting system;

FIG. 4 is a schematic block diagram of an embodiment of a sound signal detection and alerting device (SSDAD);

FIG. 5 is a flowchart illustrating an exemplary operation of an embodiment of a SSDAD;

FIG. 6 is a diagram illustrating the bearers set up for an LTE cellular network connection;

FIG. 7A illustrates an example format of a message payload for purposes of illustration and not limitation;

FIG. 7B illustrates the format of an IP packet transmitted from the MDAD to the nearest eNB in FIG. 3.

FIG. 7C illustrates the format of an S1 GTP IP packet;

FIG. 7D illustrates the format of an S5 GTP IP packet;

FIG. 7E illustrates an extracted IP packet;

FIG. 8 is a flow diagram illustrating operation of an exemplary embodiment of a Notification Service;

FIG. 9 is a network diagram of an exemplary embodiment the architecture of the Notification Service;

FIG. 10 is a format diagram of a record stored in the Subscriber database;

FIGS. 11A-11E are operational pseudo-code of command sequences performed the Notification Service in conjunction with the SSDAD;

FIG. 12 is a block diagram of an exemplary embodiment of a sensor alert notification device;

FIG. 13 is a block diagram of a network environment in which a SAND may operate; and

FIG. 14 is a high-level format of a message that is transmitted by a sensor.

DETAILED DESCRIPTION OF THE INVENTION

In general, a sound alarm is a device that generates a sound signal upon the detection of an alarm condition. A sound signal is a longitudinal mechanical wave that travels through a non-vacuum medium (such as ambient air on Earth, water, solids, etc.) and is generated by a source that causes variation in pressure of the medium, resulting in the sound wave(s). Due to its wave characteristics, sound can therefore be specified in terms of wavelength, period, amplitude, phase, pressure displacement, etc., but is most often specified in terms of frequency and power. The frequency of a sound wave is measured in number of vibrations per second (represented in hertz (Hz)). The power of a sound wave is measured in decibels (dB), a logarithmic scale, where 0 dB represents the human threshold of hearing (i.e., the faintest level of sound that a young healthy human can hear) and each increase in power by 10 dB represents a doubling of power (or sound pressure). Generally, the range of human-audible sound is considered to be in the range of approximately 20 Hz to 20,000 Hz. Sound outside of this range is considered human-inaudible sound.
A sound signal generated by a sound alarm may be audible or inaudible to humans, depending on the purpose and application of use of the sound alarm. For example, a sound alarm may be a smoke and/or carbon monoxide detection and alarm device which generates a human-audible sound signal upon detection of smoke and/or carbon monoxide above respective predefined thresholds in the proximate environment. Another example of a sound alarm is an intrusion alert alarm device which generates a sound signal upon detection of an intruder to secured premises. Other examples of sound alarms, given by way of example and not limitation, that may generate either human-audible or human-inaudible sound signals, include: a chirp alarm which generates a short “chirp” sound upon the detection of a low-battery condition of a device, an automobile alarm which generates a sound alarm when the automobile in which it is mounted is touched and/or tampered with; an anti-theft alarm which generates a sound signal when an object is moved or otherwise intruded upon; an activation alarm which generates a sound signal upon the activation of another sensor or detection of a predetermined condition, etc. Examples of inaudible sound alarms include animal deterrence alarms in which a human-inaudible sound signal that is audible by certain animals (e.g., rodents, pets, or other animals) is generated upon detection of an animal crossing a threshold, or which may sound continuously to deter animals from coming near.
FIG. 1 is a system diagram of an exemplary environment implementing a sound alarm notification system 1 in accordance with an embodiment of the invention. In general, a sound alarm system 1 includes a sound generating device 2 (hereinafter “sound alarm”) which generates a sound signal when powered or switched on or upon detection of one or more predetermined conditions. In an embodiment, the sound alarm is an electronic apparatus having at least one sensor that detects an event or condition, and a sound generator such as a siren, a buzzer, an electronic voice, a vibration. Generally, such sound alarms include an electronic controller responsive to signal(s) generated by electronic sensor(s), a sound generator responsive to a signal from the controller to generate a sound, an amplifier which amplifies the sound, and a speaker which transmits the amplified sound.
Returning to FIG. 1, the sound alarm 2 is installed in, placed in, mounted in, integrated into the structure of, or otherwise positioned in, a defined environment 3. The defined environment 3 may be defined to be any area of any closed or open environment, or combination thereof. For example, the sound alarm 2 may be mounted in the ceiling or wall of a room in a building, and the defined environment 3 may be the specific room in which the sound alarm 2 is mounted. As another example, the defined environment 3 may be characterized as the entire area within the vicinity of the sound alarm 2 in which sound generated by the alarm 2 can be detected as meeting certain characteristics, wherein areas outside of such vicinity is considered outside the boundary of the defined environment 3. Such characteristics may be, for example, sound detectable at or above a certain threshold power level (e.g., measured in dB), sound characterized by a predetermined frequency or frequency range, a sound signal having an audio signature that matches a predetermined audio signature, etc. In such example, the defined environment 3 may be the set of rooms and other interior space of a building where sound generated by the sound alarm 2 is detectable above a predetermined threshold measured in dB (e.g., 80 dB). As another example, the defined environment 3 may be an exterior space, such as a parking lot or construction lot, in which a sound alarm 2 is installed and where the points between detectable sound at or above a predetermined threshold (e.g., 80 dB) and sound below the predetermined threshold define the boundary of the defined environment 3—that is, at or above the predetermined threshold being inside the defined environment 3, and below the threshold being outside the defined environment 3.
Installed (or otherwise placed) within the defined environment 3 is a sound signal detection and alerting device (SSDAD) 5. SSDAD 5 includes a sound detection device (SDD) 5 a, a controller (CTL) 5 b, and a radio transmission module (Tx) 5 c. Sound detection device 5 a detects sound generated by sound alarm 2. Controller 5 b is responsive to detection of sound by sound detection device 5 a and generates notification messages for transmission by radio transmission module 5 cover one or more networks 6 to a remote notification service 7. SSDAD 5 is registered with notification service 7. In a preferred embodiment, notification service 7 is accessible via a packet data network (PDN) such as the Internet, but it is to be understood that notification messages may be transmitted from SSDAD 5 and routed to notification service 7 across multiple different networks having different physical and logical communication stacks/protocols, such as one or more different cellular networks and/or one or more different packet data networks.
Notification service 7 stores registration information in a database 8. The registration information stored in database 8 includes the device identifier for each SSDAD 5 that is registered with the notification service 7, along with corresponding recipient and delivery service information associated with each registered SSDAD 5. In an embodiment, database 8 stores the device ID of each registered SSDAD 5, along with, for each device ID, one or more delivery addresses and corresponding indications of electronic delivery services which are to be used to deliver a notification to the corresponding respective delivery addresses. Such a schema allows for notification to one or more notification recipients via various notification delivery mechanisms. For example, for a given registered SSDAD 5, notification may be sent to one or more recipients via their respective chosen notification methodology (e.g., email, SMS text, in-app push notification, etc.) so that they can receive notification via their respective preferred technology.
For example, for a given SSDAD 5, notification may be set up to be delivered via email to a particular user's (a “recipient”) email address, via SMS text to a recipient's mobile phone number, and to a recipient's app executing on the recipient's smart phone (and addressed via the smart phone number or email address). A different SSDAD 5 (not shown in FIG. 1) associated with a different subscriber and having a different device ID may be set up so that a notification is delivered, for example, only via SMS text to a different recipient's mobile phone number. The described registration schema contemplates the ability to allow different subscribers associated with different registered SSDADs to individually configure notification recipient information and preferences. In embodiments, users of notification service 7 can select and set up delivery service(s) and corresponding notification recipients to be notified by the service, via a web-enabled app, a website portal or API. While it is contemplated that the notification service 7 supports user-configurable notification preferences, it is also within the scope of the invention that the delivery service(s) and recipients are predetermined and/or configured by an administrator or other entity.
In operation, upon detection of a sound signal from the sound alarm 2 (and potentially upon the detection of one or more additional environmental and/or the calculation of one or more conditions based on a calculated or state machine condition or state of SSDAD 5), the SSDAD 5 sends an alert, via the radio transmission module 5 over one or more networks 6, to notification service 7. Upon receiving an alert from the SSDAD 5, notification service 7 determines the device ID of the SSDAD 5 that sourced the alert, identifies the notification recipient delivery address(es) and corresponding electronic delivery service(s) associated with the device ID, and sends a notification to, preferably each of, the identified notification recipient delivery address(es) associated with the device ID via the identified corresponding delivery service(s). In this way, notification recipients of electronic messages accessed on remote electronic devices 9 (such as but not limited to one or more smartphones 9 a, computers 9 b, cell phones 9 c, tablets 9 d, and/or laptops 9 e, collectively 9) can be informed when a sound alarm 2 generates an alarm sound in the defined environment 3, even while such notification recipients are remote and outside the defined environment 3.
FIG. 2 is a flowchart illustrating an exemplary embodiment of a notification service method 10 for notifying recipients of a detected sound alarm condition. According to the method 10, SSDAD 5 is installed within a defined environment 3 in which the SSDAD 5 can detect sound from a sound alarm 2 (step 11). Under one more condition(s), the sound alarm 2 may generate a sound signal. SSDAD 5 monitors the defined environment 3 for a sound signal generated by sound alarm 2 (step 12). Upon detection of a sound signal, SSDAD 5 determines whether to send an alert to the notification service 7 by checking whether one or more conditions are met (step 13 a). As an example of such a condition, a sensor in the SSDAD 5 may detect sound, yet the SSDAD 5 will only determine to send an alert to notification service 7 if the sound is above a predetermined signal strength (e.g., above a certain dB level).
Upon determination to send an alert (step 13), SSDAD 5 formats an alert message into a format suitable for transmission by radio transmission module 5 c (step 14) and transmits the formatted alert message to notification service 7 (step 15). In an embodiment, SSDAD controller 5 b formats an alert message that contains at least a device identifier (the device ID) of the SSDAD 5, and an alert code or other message that may be processed by notification service 7 for use in determining what, how, or whether to notify notification recipients associated with the SSDAD 5. In an embodiment, SSDAD controller 5 b coordinates with the transmission module 5 c to send the alert message to notification service 7. Transmission module 5 c transmits the alert message (using an appropriate network protocol) over radio waves using radio frequency (RF) transmission. A radio access network (included in network(s) 6) includes an RF receiver that receives the alert message, and passes it on to one or more additional networks 6, where it is further transmitted, routed, processed (step 16), and ultimately received (step 17), processed and decoded by notification service 7.
Notification service 7 receives the alert message, processes the message to extract the message payload (i.e., the substantive contents of the message) (step 18), and decodes the alert message to identify the SSDAD 5 which sent the alert (step 19). The payload of the message contains the SSDAD ID. The notification service 7 uses the SSDAD ID to look up or otherwise identify one or more notification recipients and corresponding delivery service(s) by which each recipient should be notified (e.g., text, email, voicemail, in-app notification, etc.) (step 20).
As discussed hereinafter, the extracted payload of the alert message further includes a code indicating the substantive alert condition from the sending SSDAD 5. The notification service 7 decodes the code and constructs a human comprehensible message in the appropriate format of the delivery service(s) for each identified delivery service corresponding to each notification recipient (step 21). Delivery services may include such services such as a text (SMS) delivery service, an email delivery service, an in-app notification delivery service, a voicemail delivery service, and/or any other type of delivery service that delivers content such as text, audio, video, images, app-push notifications, etc., to an end-user device. The format of the human-comprehensible message will depend on the particular delivery service. For example, an SMS delivery service requires a text message; an email message requires text or an attachment, a voicemail delivery service requires an audio file containing human-understandable audio content, an in-app notification delivery service may contain text, an image containing human-understandable message, an audio/video clip, a document, etc.
Referring once again to FIG. 2, notification service 7 then finally sends the constructed notification message(s) via the corresponding delivery service(s) to the notification recipient delivery address(es) for the identified notification recipient(s) associated with the identified SSDAD 5 (step 22).
FIG. 3 is a network architecture diagram of an exemplary environment 100 implementing a sound signal detection and alerting system. In a preferred embodiment, the system is designed such that an SSDAD 105 can be installed in remote locations that may not have access to power and/or may not have (reliable) WiFi for accessing the Internet 120, yet can still transmit alert messages to a Notification Service 123 which is connected to the Internet 120. With these parameters in mind, power to the SSDAD 105 is therefore preferably supplied solely from a battery supply (or optionally a standalone power source such as a solar power supply), and the SSDAD 105 accesses the Internet 120 to communicate with the Notification Service 123 using a Low Power Wide Area Network (LPWAN) such as a Low Power cellular network (for example, a CAT-M1, CAT-NB1 or EGSM-IoT enabled network).
In the environment 100 shown in FIG. 3, a SSDAD 105 is installed in a defined environment 103 where the SSDAD 105 should be able to pick up the type of sound or vibration that is desired to be monitored. SSDAD 105 monitors the defined environment 103 for sound/vibration. Upon detection of sound/vibration, SSDAD 105 may connect to the Internet, via a Low-Power Cellular Network 110 (shown as an LTE-M network), to send an alert message to an Internet-enabled Notification Service 123. Notification service 123 is connected to the Internet 123 by way of a Notification Service server 122 that connects to the Internet 120.
Turning in more detail to the SSDAD 105, FIG. 4 is a schematic block diagram of an embodiment of a sound signal detection and alerting device (SSDAD) 200 that may be used to implement the SSDAD 105 of FIG. 3 (and/or FIG. 1). As shown in FIG. 4, SSDAD 200 includes a controller 201, computer memory 202, a cellular modem 203, and an antenna 204, a Subscriber Identity Module (SIM) 205, a sound detection device 206, and a battery supply 207 which is electrically coupled to, and supplies power to, all the electronic components of the SSDAD 200. SSDAD 200 may optionally include a power switch 208.
The controller 201 may be a microprocessor, a computer processing unit (CPU), a microcontroller unit (MCU), or custom application specific integrated circuit (ASIC), or other integrated circuit (IC), or non-integrated circuitry, that is electrically coupled to (directly or indirectly), or has embedded therein, computer memory 202.
Computer memory 202 comprises computer readable storage media, preferably in the form of one or more, or any combination, of Programmable Read-Only Memory (PROM, EPROM, EEPROM, flash EPROM), and/or Random Access Memory (RAM, DRAM, SRAM, SDRAM, etc.). Computer memory 202 stores program instructions executable by the controller 201 to perform the operative steps for implementing the invention. The computer memory 202 further stores data which may be used by the controller 201 in its operations. Computer memory 202 stores an identifier, such as a serial number, that is unique to the SSDAD 200. The computer memory 202 may be integrated or embedded within the integrated circuit (IC) implementing the controller 201 or may be standalone memory IC(s) electrically coupled to the controller via one or more busses.
Cellular modem 203 is electronic circuitry typically fabricated in the form of an integrated circuit (IC) that contains the hardware and control functions for implementing the RF communication. In particular, a typical cellular modem 203 contains a controller/CPU, integrated computer memory, signal encoding/decoding circuitry, a power amplifier, and a baseband processor which includes multiplexing/demultipexing, channel selection, carrier generation, and modulation circuitry. Such cellular modem 203 stores in its integrated computer memory an International Mobile Equipment Identifier (IMEI) to allow a cellular network to identify the modem 203 (or the user equipment (UE) in which the modem is installed, such as the SSDAD 200). SIM 205 stores a unique Integrated Circuit Card Identifier (ICCID) that is converted by a cellular network into a network subscriber's International Mobile Subscriber Identity (IMSI) number to thereby identify the subscriber to the cellular network.
In an embodiment, cellular modem 203 is responsive to telephone Attention (AT) commands for controlling the modem 203, and converts digital messages into RF transmission signal suitable for the network on which it is transmitted. For example, where the cellular modem 203 is implemented to connect to an LTE-M cellular network, the cellular modem 203 is configured to transmit signals on the antenna 204 according to a CAT-M1 protocol. The cellular modem 203 is further configured to receive RF signals carrying messages from the Notification Service 107 and to convert the received signals into a digital format recognizable by the controller 201.
Sound detection device 206 comprises one or more sensors that detects sound/vibration, and generates at least one output signal based on detected sound/vibration. In an embodiment, sound detection device 206 generates, on an output port (such as a pin or pad), an output signal representative of a magnitude, or amplitude, of detected sound. In an embodiment, the output signal may be a signal between two voltage rail values (e.g., for purposes of example only and not limitation a low rail value of 0V and a high rail value of 1.8-3.3 V) and the voltage level of the output signal is representative of the magnitude of detected sound/vibration. In an alternative embodiment, the output signal of the sound detection device 206 is a binary signal which is mapped in a first state (either low or high voltage) when no sound/vibration is detected or when detected vibration is (at or) below a trigger threshold, and in a second state (voltage level being the opposite of the first state) when detected sound/vibration is (at or) above the trigger (or a second trigger) threshold.
In an embodiment, sound detection device 206 is an electronic circuit or component, such as an accelerometer 206 a or a microphone 206 b. Alternatively, sound detection device 206 could comprise a sound signature matching circuit. In an embodiment, such sound signature matching circuit comprises a microphone 206 b, a signal processor 206 c which receives incoming sound and generates a sound signature, and a processor 206 c or 201 which determines whether incoming sound signature(s) match a stored sound signature. In an embodiment, the sound signature matching circuit includes circuitry which implements a recording feature enables recording of a sound. As an example use case, a sound alarm may generate a specific sound, such as a chirp, an electronic simulated voice saying a particular word or phrase (e.g., “Danger. Fire!”). In this embodiment, the recording feature of the SSDAD 200 allows a user to record the sound that the alarm makes when activated to extract a sound signature. The signature of the recorded sound is generated by the signal processor and stored in local computer memory. The computer memory may store a sound signature received from Notification Service 123 or other remote service or which is generated by the signal processor 206 b from the recorded sound obtained via the optional recording feature. A processor compares the sound signature of incoming sound to a stored sound signature and generates an output signal indicating a detected match on the sound detection device output port upon detecting a signature match between the incoming sound signature and the recorded sound signature. The processor may be integrated into the signal processor 206 b, or may be independent of the sensors 206 b. For example, the controller 201 may perform the signature comparison processing.
Structurally, controller 201 is electrically coupled to sound detection device 206 and cellular modem 203. In an embodiment, controller 201 is coupled, directly or indirectly, to receive the output signal(s) of sound detection device 206 and executes hardware logic or program instructions based on the received output signal(s). Generally, when sound detection device 206 detects sound/vibration at or above a predetermined threshold level, it generates one or more output signal(s) indicating the condition. In an embodiment, controller 201 comprises a microprocessor that is capable of processing an interrupt received on an interrupt input port (e.g, a pin or pad of the microprocessor). Sound detection device 206 generates a trigger signal on an output port of sound detection device 206. The output port of the sound detection device 206 is electrically coupled (directly or indirectly) to the interrupt input port of the microprocessor, and the signal present on the output port of sound detection device 206 serves as an interrupt signal to the microprocessor. When the output signal of sound detection device 206 indicates that it is in a triggered state (indicating sound/vibration detected (at or) above a trigger threshold), it generates an interrupt within the microcontroller, causing the microcontroller to run an interrupt service routine to perform several actions. In particular, the microcontroller may formulate an alert message and send commands to cellular modem 203 to set up and transmit the alert message.
In an alternative embodiment, sound detection device 206 converts sound/vibration waves into an electronic signal. The electronic signal itself, or an amplified, demodulated, decoded, ND converted, and/or otherwise processed version of the electronic signal, may serve as the output signal of the sound detection device 206. In this embodiment, the output signal may be input to a digital signal processor, a threshold comparator, and/or the controller 201 itself, each of compares the received signal with a predetermined threshold or a matching signature, to determine whether or not an alert message should be sent to notification service 123.
Cellular modem 203 adheres to a predetermined transmission protocol stack, as predefined based on the protocol used for communicating with the cellular service to which the SSDAD 105/200 subscribes. As is required generally for cellular modems that need to pass messages from a mobile device through a cellular network to a packet data network (e.g., the Internet), the cellular modem 203 includes circuitry and programming to encode an alert message generated by the controller 201, encapsulate the encoded message into one or more packets, and perform the signal processing required to adhere to the data transmission scheme(s) recognized and used by the cellular network 110 for data uplink (from SSDAD 105 to cellular network) and data downlink (from cellular network to SSDAD 105). For example, in an LTE-M enabled cellular network, the cellular modem preferably is capable of packetizing data in accordance with TCP/IP or UDP protocol, and includes hardware that transmits packet data according to LTE CAT-M1, including a SC-FDMA, 15 KHz tone spacing, Turbo Code, 16 QAM modulation scheme, and receives data based on OFDMA, 15 KHz tone spacing, Turbo Code, 16 QAM modulation scheme. Other types of cellular networks use different modulation schemes implemented in accordance with the standards promulgated by worldwide organizations such as 3GPP, IEEE, and GSMA.
In an embodiment, SSDAD 105 is designed to operate using a stand-alone power supply 207 (e.g., the SSDAD 105 is battery or solar powered). In such embodiment, SSDAD 200 is preferably implemented using ultra-low-power components. By way of example and not limitation, in an embodiment, controller 201 comprises an ultra-low-power microcontroller unit (MCU) with integrated flash memory and an integrated EEPROM such as an STMicroeletronics STM8L151C8 IC, which consumes 200 μA in normal operating mode and less than 6 μA when placed in a low power mode.
Further, in an embodiment, cellular modem 203 is implemented using a Quectel LPWA Module BG96, manufactured by Quectel Wireless Solutions Co., Ltd., headquartered in Shanghai, China. The Quectel BG96 Cat.M1/NB1 & EGPRS Module can transmit according to CAT-M1 or CAT-NB1 protocols over existing LTE/Extended GPRS (EGPRS) networks, consuming only 10 μA in power saving mode (PSM) and 190 mA when transmitting at 23 dBm. The Quectel BG96 is programmed to use CAT-M1 protocol when connecting to an LTE-M cellular network, and is programmed to use CAT-NB1 protocol when connecting to an NB-IoT enabled cellular network.
Further in an embodiment, sound detection device 206 is preferably an ultra-low-power device such as Micro-Electro-Mechanical Systems (MEMS) accelerometer 206 a or MEMS microphone 206 b that is implemented using microfabricated miniaturized electro-mechanical elements (on the order of micro, femto and nano-meters) and which by design consume very low power. In an embodiment, sound detection device 206 is implemented using a STMicroelectronics LIS2DE12, which is a 3-axis MEMS accelerometer characterized by ultra-low-power consumption down to 2 μA, and allows for programmable sensitivity. An accelerometer can be used as a sound detection device 206 due to the fact that sound waves create variation in air pressure, and the change in air pressure can be measured by measuring the acceleration of internal moving parts, such as a diaphragm or other anchored movable objects. The LIS2DE12 MEMS accelerometer is fabricated using micromachined silicon structures that are anchored at a few points and are free to move in the direction of acceleration. Sensing element(s) within the LIS2DE12 sense displacement of the silicon structures from their nominal positions resulting in a change in capacitance thereof and can be measured using charge integration in response to a voltage pulse applied to the capacitor structure. When an acceleration is applied to the LIS2DE12 sensor, the mass of silicon structures displace from their nominal positions, and the displacement is measured using a capacitive half-bridge. The change in capacitance is measured using charge integration in response to a voltage pulse applied to the capacitor. At steady state the nominal value of the capacitors are a few pF and when an acceleration is applied, the maximum variation of the capacitive load is in the fF range. The LIS2DE12 MEMs accelerometer can be programmed to generate an interrupt upon detection of different levels of acceleration (measured in g's). The LIS2DE12 provides full scales of ±2 g/±4 g/±8 g/±16 g and is capable of measuring accelerations with output data rates from 1 Hz to 5.3 kHz.
Sound detection device 206 may alternatively be implemented using a microphone, for example a MEMS microphone such as an MP23ABS1 manufactured by ST Microelectronics. The microphone detects sound and generates an electrical output signal representative of the sound. The output of the microphone may be electrically connected to the input of an op-amp circuit which generates a binary signal that is in one state (voltage level) when the detected sound is below a threshold, and is in a second state (voltage level) when the detected sound is at or above the threshold. The output of the op-amp circuit may be connected to the interrupt port of the controller 201 to signal that sound at or above the programmed threshold has been detected. The op-amp circuit may be programmable by the controller 201 to set or change the feedback resistance values in order to set the threshold for alerting the controller 201.
Further to implementations comprising a limited battery power supply, SSDAD 200 preferably implements several power conservation techniques, including employing a controller 201 and a cellular modem 203 that can each be placed in a Power Saving Mode (PSM) state. In PSM, features of the controller 201 and cellular modem 203 which draw higher power are shut down and/or placed in a sleep mode when the respective devices are placed in the PSM state. For example, cellular modem 203 turns off power to antenna 204 when in the PSM state. Design selection of the particular implementation of cellular modem 203 must of course take into consideration the particular network 110 over which alert messages are to be transmitted to ensure that the cellular modem 203 is capable of transmitting according to the protocol required by the selected network. To conserve battery power, in a preferred embodiment SSDAD 200 is implemented to communicate using a low-power signal over a LPWAN such as an LTE-CATM1, NB-IoT, or EC-GSM-IoT network, which specifies a transmission signal strength of 23 dBm.
FIG. 5 is a flowchart illustrating an exemplary operation 210 of SSDAD 200. As shown, in operation, when SSDAD 200 is powered on, for example by turning on power switch 208, controller 201 performs an initialization (step 211). Once controller 201 is initialized, it monitors the Ready status of cellular modem 203 (step 212). Typically, the cellular modem 203 includes a status pin output which controller can monitor.
At first power up, cellular modem 203 also performs an initialization (step 221), including readying the antenna for transmission and/or reception (step 222). Once the cellular modem has completed initialization and the antenna is ready to transmit and/or receive, it indicates to controller 201 that it is ready. Typically, this is accomplished by setting an output status pin to a Ready state, which controller 201 monitors.
When controller 201 determines that the modem is ready (step 212), controller 201 obtains the ICCID, the IMEI, and SSDAD identifier (step 213). In an embodiment, the ICCID is integrated into the SIM 205, and controller 201 instructs cellular modem 203 to access SIM 205 to obtain the ICCID of the SIM 205. In an embodiment, the IMEI is programmed into an EEPROM integrated into the cellular modem 203, and controller 201 issues a command to cellular modem 203 to obtain the IMEI. In an embodiment, the manufacturer of the SSDAD 200 issues a unique serial number for each SSDAD at the time of manufacture, and stores it in a PROM or other memory 202 accessible by the controller 201.
Once the ICCID, IMEI and SSDAD identifier (e.g., Serial Number) are obtained, controller 201 then instructs=cellular modem 203 to connect to the subscriber network (step 214). In particular, cellular modem 203 is programmed to recognize various AT commands to control communication using the modem. In an embodiment, cellular modem 203 is configured with an embedded TCP/IP protocol stack, and the AT commands are translated into messages/responses, encapsulated into TCP/IP packets and transported over the LPWAN network according to the TCP/IP protocol. In an embodiment, controller 201 instructs cellular modem 203 to connect to the subscriber network 110 by (1) configuring a Packet Data Protocol (PDP) Context with the network Access Point Name (APN), the subscriber name, password and authorization type (step 214 a), (2) configuring the Quality of Service (QoS) settings (step 214 b), (3) activating the PDP Context (step 214 c), (4) querying the network for the IP address of the PDP context (step 214 d), and (5) opening the connection (step 214 e). Once the connection is open, SSDAD 105 is able to send and/or receive requests/commands/responses and data (step 215) to/from the Notification Service 123. In an embodiment, the send/receive step 215 may include sending SSDAD status, sound/vibration detection alerts, and communication acknowledgements to Notification Service 123, and/or receiving communication acknowledgements, messages, SSDAD settings or firmware updates from Notification Service 123.
In order to conserve power, the controller 201 is programmed to execute sequences of communication handshakes that comprise a series of commands/requests and corresponding responses and acknowledgements for accomplishing sending messages to the cellular network 110 service (such as a connect request to access the cellular network 110), sending messages to the Notification Service 123 (such as sending a sound/vibration detection alert message), and receiving one or more messages or data (such as handshake and application acknowledgements, SSDAD settings and updates, and firmware updates). These sequences are programmed into the program memory 202 used to instruct the actions of the controller 201. FIGS. 11A-11E illustrate several example communication sequences, discussed hereinafter.
The programming of controller 201 according to predefined communication sequences enables another power saving mode technique, namely providing a way for the controller 201 to recognize that a communication sequence is complete, the completion of which is used by the controller 201 as a trigger to place the cellular modem 203 and itself into a Power Saving Mode (PSM) (step 216). In PSM, each of the controller 201 and the cellular modem 203 turn off or place in a low-power state certain respective features that require and/or consume (relatively) more power than other device features for operation. For example, the cellular modem 203 may disable the power to the antenna 204 (step 225) and then enter PSM (step 226) so that battery power is not consumed powering the antenna during periods when the controller 201 enters a state, by way of the programmed communication sequences, that does not require sending a message to, or expecting a message from, the network or notification service. For example, once the controller 201 completes a communication sequence (step 215) and instructs the cellular modem 203 and itself to enter PSM (step 216), it enters a very low power mode while awaiting an interrupt from the sound detector sensor 206. In this state, because the antenna 204 is disabled, the cellular modem 203 cannot receive messages from the network 110. Thus, when the controller 201 places the SSDAD 105 into PSM, communication is one-way only in the direction from the SSDAD 105 to the network 110. When the SSDAD 105 is in the PSM state, the Notification Service 107 cannot contact the SSDAD 105.
In an embodiment, the SSDAD 105 exits PSM when sound detection device 206 interrupts controller 201 when sound/vibration is detected that corresponds with an alert condition. For example, the alert condition may be that sound/vibration detected by the sound detection device 206 is characterized by a sound/vibration parameter that exceeds, reaches, or goes below a programmed threshold. As an example, sound detection device 206 may interrupt the controller 201 when detected sound/vibration exceeds a predetermined level, such as 10 dB. In another embodiment, sound detection device 206 may process detected sound, compare the detected sound with a preprogrammed signature, and interrupt the controller 201 when the detected sound matches the preprogrammed signature.
Returning to FIG. 5, when controller 201 receives an interrupt signal from sound detection device 206, it exits from PSM (step 217), formulates an alert message (step 218) and wakes up the cellular modem 203. The controller 201 then, in coordination with cellular modem 203, executes a communication sequence (step 215) to notify the Notification Service 123 of the alert condition. Upon completion of the command sequence, controller 201 then places the SSDAD 200 into PSM once again (step 216).
The PSM state of cellular modem 203 is controlled by controller 201. Controller 201 places cellular modem 203 into PSM, and wakes up the cellular modem 203 by instructing it to exit PSM. When instructed to exit from PSM, exits PSM (step 227) and enables its antenna (step 228). Cellular modem 203 then awaits AT commands from controller 201 (step 223) and processes AT commands (step 224) in normal operating mode.
Returning to FIG. 3, in a preferred embodiment, the cellular network 110 is preferably a Low Power Wide Area Network (LPWAN) transmission module, which supports low-complexity, deep-coverage devices. By way of example and not limitation, exemplary LPWANs include LTE-M (including CAT-M1), EC-GSM-IOT, and NB-IOT cellular networks. In a preferred embodiment, the LPWAN implements the 3GPP LTE-M (CAT-M1) specification and protocol, which support devices characterized by low power transmission (max transmit power of 23 dBm), provides a low maximum system bandwidth (1.4 MHz), and allows a relatively low maximum peak data rate (1 Mbps).
In the embodiment shown in FIG. 3, SSDAD 105 is configured to transmit alert messages over a radio access network (RAN) 118 that supports low power wide area network technologies. In FIG. 3, the radio access network 118 is a cellular LTE-M network operating in the licensed (i.e., regulated) spectrum. The LTE-M network operates over the same (or subset thereof) frequency bands as LTE) and implements 3GPP LTE-M specifications and protocols utilizing the existing LTE cellular infrastructure. An LTE cellular network includes a RAN 118 and a core-all-IP network 119. In LTE terminology, RAN 118 is referred to as the Evolved Universal Mobile Telecommunications System (E-UMTS) Terrestrial Radio Access Network (E-UTRAN), and the core all-IP network 119 is referred to as the Evolved Packet Core (EPC). The E-UTRAN includes a network of cellular sites 111 (shown as 111 a ₁, 111 a ₂) providing areas of network coverage arranged in geographical “cells” across areas of Earth. Each cellular site includes at least one antenna 111 b ₁, 111 b ₂mounted on a cell tower, which is designed to transmit and/or receive signals on a designated LTE-M frequency band. Within a given cell, transmitted signals adhere to minimum signal strength specifications so as to cover at least the entire area of the geographical cell. In practice, each cellular tower has multiple antennas sending and receiving over multiple LTE/LTE-M frequency bands, and each antenna 111 b ₁, 111 b ₂is tuned to receive and/or transmit signals on various frequencies and in different directions. Each antenna 111 b ₁, 111 b ₂of a cellular site 111 a ₁, 111 a ₂is connected by wire or fiber optic cable to a base station 111 c ₁, 111 c ₂(which in the LTE/LTE-M RAN is referred to as an Evolved Node B, eNodeB, or eNB).
The base station 111 c ₁, 111 c ₂, or eNB, is the primary interface for connecting subscribing user equipment devices (UEs) to other devices and services serviced by the particular LTE/LTE-M network service provider (often called the “carrier”, such as commercial providers Verizon, AT&T, etc.). The base station is also the primary interface between subscribing devices and networks of other providers (such as other RANs, packet switched and packet data networks). The eNB 111 c ₁, 111 c ₂manages the radio interface between user equipment (UE) devices (such as mobile and/or remote LTE and LTE-M enabled devices) and the core network (referred to as the Evolved Packet Core (EPC)) 119 which connects and routes messages between remote UEs subscribing to the LTE/LTE-M cellular network and UEs and other devices on networks of other carriers or packet data networks such as the Internet.
Referring again to FIG. 3, RAN 118 provides connection between LTE-enabled devices 105, 109 and the core network 119. The core network 119, or EPC, is an all-IP (Internet Protocol) network that manages the interconnection of calls and data flow between devices connected to the RAN 118, to one another and to other networks 130 and/or packet data networks (PDNs) 120 and resources connected to the core network 119. The core network 119 forms the central control of the cellular network 110. Among other functions, the core network 119 manages authentication of user equipment (UE) (such as SSDAD 105 and other UEs such as cellular enabled mobile devices 109) requesting access to the cellular network 110, voice/data call and message control/switching/routing, allocating resources to meet subscriber quality of service levels, and setting up data traffic tunnels (known as bearers) between authenticated UEs to packet data network (PDN) gateways 115 for transfer of user traffic between the UEs and PDNs (such as the Internet 120).
In the LTE-M network, the core network (EPC) 119 includes a Mobility Management Entity (MME) 112, a Home Subscriber Server (HSS) 113, a Serving Gateway (S-GW) 114, a Packet Data Network Gateway (P-GW) 115. MME 112 operates as the main control entity for the LTE radio access network (E-UTRAN). MME 112, with the assistance of an eNB 111 c within connection range of a UE and HSS 113 which hosts network subscriber information, manages authentication of UEs requesting access to the network 110. MME 112 also manages control plane (Non-Access Stratum (NAS)) signaling, including mobility management, session management, and setup of tunnels, or “bearers” that carry user plane traffic. MME 112 communicates with eNBs 111 c ₁, 111 c ₂, (and others not shown) in the radio access network 118 via the LTE S1-MME interface, while eNBs communicate with UEs via the LTE-Uu interface. When a UE 105/109 requests access to the network 110, the eNB 111 c of the cellular site 111 a having the antenna 111 b receiving the UE signal with the greatest signal strength (usually the eNB 111 c of the cellular site 111 a nearest the requesting UE 105/109), along with both the UE 105/109 and the MME 112 serving the eNB 111 c, coordinate with each other to perform mutual authentication. In LTE networks, both LTE-enabled UEs and the LTE network follow well-known pre-defined LTE authentication protocols to ensure, from the UE's point of view, that the UE is accessing the network 110 it thinks it is accessing and, from the network's point of view, that the UE has authorization to access the network 110 and is the user equipment that the UE says it is. The communication interfaces and protocols for LTE-M, including among others the LTE-Uu, LTE-S1, LTE-MME, LTE-S5 and SGi interfaces, are specified and published by 3GPP, available at www.3gpp.org, and are incorporated herein by reference for all that they teach
When a UE, such as SSDAD 105, is authenticated, MME 112 sets up an IP connection (or “session”) between the UE and a particular Packet Data Network (PDN). Profile information associated with the authenticated UE is accessible through the Home Subscriber Server (HSS) 113 (and/or a Profile Repository (not shown)), which stores default PDN IP address associated with the UE. The UE can also specify a specific IP address during the access request. MME 112 determines the IP address of the PDN with which the UE wishes to connect, using the default IP address from the UE profile information or from UE request information. The UE can have either a static IP address or may be dynamically assigned an IP address using standard Dynamic Host Configuration Protocol (DHCP) or other dynamic IP address allocation protocols. The session identifies the connection endpoint IP addresses, namely the IP address of the UE and the IP address of the PDN (also called the Access Point Name (APN)) through which the UE wishes to connect (presumably to use services).
In conjunction with setting up the session, MME 112 also sets up a default Evolved Packet System (EPS) bearer, which is a tunnel through which IP packets are transferred through the LTE network 110 between the UE and a PDN gateway (P-GW) that serves the destination PDN. With reference to FIG. 6, the default EPS bearer requires setting up of three different bearers due to the different communication interfaces between equipment located between the UE and P-GW (including the eNB, the S-GW and the P-GW). In the UE-to-P-GW direction, data flows from the UE to an eNB 111 c via a data radio bearer (DRB) using the LTE-Uu interface, then from the eNB to the S-GW via the S1 interface, then from the serving gateway (S-GW) to the PDN Gateway (P-GW) using the LTE S5 interface. Accordingly three different bearers are set up to accommodate the different interfaces, which include a DRB (i.e., data tunnel) to deliver user data traffic between the UE and eNB using the LTE-Uu interface, an S1 bearer to deliver user data traffic between the eNB and S-GW, and an S5 bearer to deliver user data traffic between the S-GW and P-GW. MME 112 coordinates with the eNB 111 c, the HSS 113, the S-GW 114 and P-GW 115 to set up these bearers. FIG. 3 details a small few cellular sites (eNBs) 111 a ₁, 111 a ₂, a single MME 112, S-GW 114 and P-GW 115, for the purposes of simplicity of illustration and explanation and not by way of limitation. It is to be understood that in practice, commercial LTE/LTE-M networks comprise many cellular sites 111 a, which may connect to several different MMEs 112, which are each connected to several S-GWs 114 and P-GWs 115, serving different geographical locations of the overall cellular network. In an embodiment, the cellular network service provider through which SSDADs 105 gain access to the cellular network 110 for subsequent transmission and receipt of messages over the Internet to and from the Notification Service 123 is a 3rd-party commercial cellular network service provider that supports LTE-M, such as, by way of example only and not limitation, Verizon or AT&T.
LTE/LTE-M networks are all-IP networks, meaning that all user traffic is delivered by way of Internet Protocol (IP) packets. When an LTE-enabled UE, such as SSDAD 105 connects to the network 110, it is assigned an IP address, a session is set up, and data traffic bearers are set up between the UE device and a PDN gateway P-GW. The IP address assigned to the SSDAD 105 remains valid and the bearers remain connected until the SSDAD 105 is detached from the network 110. That is, the session remains valid until the SSDAD 105 is detached from the network 110.
In the network system of FIG. 3, since the LTE-M network 110 is an all-IP network, the SSDAD 105 uses the IP protocol for sending alerts. In particular, the SSDAD 105 encodes an alert message (also called the message payload) and formulates it into at least one IP packet containing an IP header and the message payload. FIG. 7A illustrates an example format of a message payload 30 for purposes of illustration and not limitation. As illustrated, the message payload comprises one or more bytes of bits 31. Groupings of the bits 31 correspond to encoded information. For example, one group 32 of bits 31 corresponds to encoded SSDAD identification information. In an embodiment, the identification information includes a unique UE/SSDAD serial number and/or other identification information. Another group 33 of bits 31 corresponds to encoded alert information, while another group 34 corresponds to encoded status information, and yet another group 35 of bits corresponds to encoded control information. In an embodiment, the identification (ID) group 32 includes a plurality of bits that uniquely identifies the SSDAD 105 to the Notification Service 123. In an embodiment, the ID group 32 comprises the serial number or an encoded version of the serial number of the SSDAD 105. It may further include additional device information such as the IMEI and ICCID. Further in an embodiment, the alert group 33 comprises one or more bits indicating whether and which of one or more alert conditions are triggered. In an embodiment, the alert group 33 comprises one or more individual bits corresponding to each of a sound or vibration detected condition and a battery low condition. The alert group 33 may comprise additional bits to represent the state(s) of additional monitored conditions. Status group 34 comprises one or more bits indicating whether the SSDAD 105 is powered on or off, and Control group 35 comprises one or more bits of encoded control information. In an embodiment, the control information indicates whether the device is to be reset or needs firmware update(s).
FIG. 7B illustrates the format of an IP packet 36 transmitted from the SSDAD 105 to the nearest eNB 111 c. As illustrated in FIG. 7B, the IP packet 36 includes an IP header 37 and the message payload 30. The IP header 37 includes a destination IP address 38 and a source IP address 39, where the destination IP address 38 is the IP address of the Internet-enabled Notification Service 123 and the source IP address 39 is the IP address of the SSDAD 105. Using the LTE-Uu interface, the cellular modem of the SSDAD 105 transmits each IP packet to the nearest eNB 111 c via the DRB bearer set up for that particular SSDAD 105. With reference to FIG. 7C, the receiving eNB 111 c receives each IP packet 36 and encapsulates each received IP packet with an S1 interface General Packet Radio System (GPRS) Tunneling Protocol (S1 GTP) header 41 to formulate an S1 GTP IP packet 40. The S1 GTP header 41 includes at least the destination IP address 42 of the destination Serving Gateway (S-GW) 114, the source IP address 43 as the IP address of the sending eNB, and an S1 Tunnel Endpoint Identifier (S1 TEID)) 44. The eNB 111 c then transfers the S1 GTP IP packet(s) 40 to a Serving Gateway (S-GW) 114 via the S1 bearer via the S1 interface. With reference to FIG. 7D, the destination Serving Gateway (S-GW) 114 strips the S1 GTP header 41 from each S1 GTP IP packet 40 and encapsulates the stripped IP packet 36 into an S5 GTP IP packet 50, including an S5 interface GTP (S5 GTP) header 51. The S5 GTP header 51 includes at least the destination IP address 52 of the destination Packet Data Network Gateway (P-GW) 115, the source IP address 53 as the IP address of the S-GW 114, and an S5 Tunnel Endpoint Identifier (S5 TEID)) 55. The S-GW 114 then transfers the S5 GTP IP packet(s) 50 to the appropriate PDN Gateway (P-GW) 115 via the S5 bearer. The receiving P-GW 115 strips the S5 GTP header 51 from each packet 50 to extract the encapsulated IP packet 36 (FIG. 7E) and transfers the packet(s) onto the Internet 120 PDN via an SGi interface. Once the IP packet is on the Internet, it is routed to the destination IP address 38 of the Notification Service 123 through conventional IP and/or Ethernet routing using TCP/IP and DHCP.
Referring again to FIG. 3, Notification Service 123 is connected to the Internet 120 and is responsive to requests addressed to its IP address (and appropriate port(s) and API calls) via the Internet 120, and further can transmit responses to requests and may send out its own requests to other devices at IP addresses on, or reachable via, the Internet 120 (and potentially additionally through a cellular network 110 to mobile cellular devices). The Notification Service 123 is an application executing on a computer system 122 that is accessible via a web server 121 connected to the Internet 120. The computer system 122 may be a central processing unit executing Notification Service program instructions stored in local or remote computer-readable memory. The Notification Service 123 may be a web-enabled service. In particular, the web-enabled service may be an instance of a Notification Service application executing in the Cloud, such as an E2C instance running on an Amazon Web Services (AWS) cloud web hosting platform.
FIG. 8 is a flow diagram illustrating operation of an exemplary embodiment of Notification Service 123. As a preliminary step, a message in the form of an IP packet 36 is transmitted from a P-GW 115 over the Internet 120 with the destination IP address of the Notification Service Server 122 and is received first by a Web Server 121 (step 61), routed to the Notification Service server 122 (step 62), which extracts the payload 30 of the received message 36 (step 63), instantiates an instance of the Notification Service 123 (step 64), passing the payload 30 to the Notification Service 123 (step 65) via a Notification Service API. Notification Service 123 decodes the message payload 30 (step 66), and performs one or more actions based on the contents of the payload (step 67).
In particular, the Notification Service 123 performs a series of appropriate steps according to predefined programming instructions. Notification Service 123 performs one side of at least some of the Communication Sequence(s). For example, it performs the Notification Service steps outlined in the Command Sequences, detailed hereinafter in connection with FIGS. 11A-11E.
In an embodiment, Notification Service 123 is software hosted on a computer system, such as a Cloud computing provider. Preferably, Notification Service 123 provides an Applications Programming Interface (API) by which users and clients can access Notification Service 123. In an embodiment, upon receipt of a proper API call the hosting computer system instantiates an instance of Notification Service 123. In particular, when other software or another system generates a Uniform Resource Locator (URL) request containing the correct IP address of the hosting computer, along with the correct path to the directory containing the executable of the Notification Service 123, and the API call is formatted correctly and contains valid parameters, the API call automatically instantiates an instance of the Notification Service 123. In an embodiment, Notification Service 123 is hosted on a computer that is accessible via the Internet. For example, Notification Service 123 may be a cloud-based service that is hosted on a server such as an AWS server connected to the Internet. In an alternative embodiment, Notification Service 123 may be a service that runs on an internal network of a closed network system.
FIG. shows a more detailed diagram of the architecture and operation of an embodiment of Notification System 123. As shown in FIG. 9, an embodiment 300 of Notification Service 123 comprises a plurality of software modules, including an encode/decode module 302, a central Control Module 301, an Administrative (Admin) module 303, a Payment module 304, a Subscriber database 305, and computer-readable storage memory (306).
Encode/decode module 302 decodes messages received from SSDADs 105 that are routed to it through the Internet from the P-GW 115 of the cellular network 110. It also encodes messages and formats them into IP packets for routing to the cellular network 110 for delivery therefrom to SSDADs 105. Central Control Module 301 operates as the central controller for the Notification Service 300 and offers one or more Application Programming Interface(s) (APIs) to allow other modules, services and devices connected to the Internet to communicate with the Notification Service 300.
FIG. 10 illustrates an example record 360 stored in the Subscriber Database 305. Each record 360 is associated with a registered SSDAD 105 and includes a plurality of fields 361, 362, . . . , 366 containing information about (1) the subscriber, (2) the respective SSDAD 105, and (3) notification service configuration(s). In an embodiment, each record 360 includes a field 361 containing a device identifier that uniquely identifies the registered SSDAD 105. In an embodiment, field 361 contains a unique serial number of the SSDAD 105. Each record 360 also includes field(s) 364 a, . . . , 364 n, that contain (either directly or indirectly using a pointer or indirect reference to) one or more notification recipient delivery service handles (username, phone number, user or device identifier, etc.) and corresponding delivery services (e.g., email, SMS text, in-app push notifications service) through which a message can be delivered to one or more person(s) corresponding to such handle(s). Each record 360 will also typically include additional fields, such as but not limited to status fields 362 indicating various status information about the PEAD 2, control fields 363 used to trigger certain remote maintenance and/or control configuration and behavior of the remote SSDAD 105. As discussed hereinafter in connection with FIG. 12, record 360 may also include one or more location-related field(s) 365, which may include such location information as most recent GPS coordinates, a log of recent GPS coordinates, and/or user-identified location description (for example an ASCII text description of the location that indicates the location of SSDAD 105). The record 360 may further include one or more firmware version field(s) 366.
Generally at least one record is stored for each SSDAD 105 that is monitored by the Notification Service 300. A typical subscriber database 305 will store thousands or hundreds of thousands or more records, corresponding to unique SSDADs 105.
Returning to FIG. 9, the nNotification Service 300 may include an administrative module 303, which allows a vendor or manufacturer of the SSDAD devices 105 to keep track of firmware versions of the SSDAD devices in the field, and to control deployment of firmware upgrades to such devices when such devices contact the notification service 300. To this end, the subscriber database 305 may further include firmware version information 365 and other status 361 and control 362 settings that may be set by the administrative module 304 to indicate to the control module 301 when one or more control operations need to be performed on a given SSDAD 105 when such SSDAD 105 next contacts the notification service 300. For example, the subscriber database 305 may include one or more bits indicating whether one or more firmware modules on the corresponding SSDAD need to be upgraded or changed to a different version of firmware. Notification Service 300 may comprise storage computer storage memory 306 which stores one or different versions of firmware, apps for the App Store(s) 307, and other administrative data, program data, and information. For example, the memory 306 may include app code and various versions thereof of an app that may be downloaded to an app store 307 and made available to SSDAD owners through such app store 307 to download to their own app-enabled device (such as a smartphone, a tablet, a laptop, or desktop), and execute their own instance 320 of the app in such local device(s) 109. For example, the notification service 300 may make available one or more apps such as and iOS app for Apple devices such as iPhones and iPads, and an Android app for Google Android devices. These apps may be made available through the Apple store or Google App Store. End user devices communicate with the app using conventional app technology such as made available through iOS and Android.
The Control Module 301 provides an API through which user apps 320 can communicate with the Notification Service 300 and configure their user profile, notification recipient information, and the settings for their own SSDAD. Such users connect to the Notification Service 300 through the app 320 running on their local device 109, which connects to the Internet directly through a LAN (via Ethernet) or WiFi, or indirectly through a cellular or other network. The app provides prompts for the user, and radio buttons and other widgets to allow the user to control device settings or opt in or out of various Notification Service settings. As an example, the app 320 may provide a slider that allows a user to set the sensitivity settings of the SSDAD (which may correspond directly to the sensor thresholds from which alerts are generated, or which may be controlled via logic in the SSDAD firmware or in the control module 300). Communication between the app 320 and control module 301 are routed using conventional TCP/IP over the Internet.
When a user installs an SSDAD 105 and subscribes to the Notification Service 300, the user enters his or her subscriber information, including subscriber details such as contact information, notification recipient information, and payment information. The Payment Module 304 handles communication with a 3^rd-party payment provider system 308 to process payments.
Each delivery service includes an Internet-enabled delivery service running on computer systems or other hardware that is connected to, and accessible via, the Internet. For example, the Notification Service 300 may utilize the service(s) of one or more SMS text services 309, one or more email services 310 such as SMTP services, one or more instant messaging services 311, one or more text-to-voice messaging services 312, one or more app push notification services 313, and one or more other messaging services 314. Such services are well-defined and adhere to conventional TCP/IP protocols for passing messages thereto.
In an embodiment, the Encoder/Decoder module 302 is the initial point of entry to the Notification Service 300 of messages issued from SSDADs 105, and is the exit point from the Notification Service 300 for messages going to SSDADs 105. Each message payload 30 coming from an SSDAD 105 is in an encoded format, for example as discussed in connection with FIG. 7A and 7E. Encoder/Decoder module 302 extracts the message payload 30 and decodes the message bits into a format or other data usable by Control Module 301. Based on the decoded information generated by the Encoder/Decoder module 302, Control Module 301 performs one or more actions. In an embodiment, these actions correspond to the Command Sequences, discussed hereinafter.
FIGS. 11A-11E illustrate a set of exemplary Command Sequences executed by an embodiment of SSDAD 105. These command sequences include an Initial Connection Command Sequence (FIG. 11A), an Alert Mssage Command Sequence (FIG. 11B), a Set Device Settings Command Sequence (FIG. 11C), an Alarm Sequence (FIG. 11D) and a Pause Sequence (FIG. 11E). These command sequences are executed by the SSDAD 105 in cooperation with the Notification Service 123. As illustrated in FIG. 11D, the Alarm Sequence is what triggers the Notification Service 123 to notify notification recipients that the SSDAD 105 has detected the monitored sound/vibration in the vicinity of the SSDAD 105. In an embodiment, the alarm sequence is initiated when the Trigger bit in the decoded message payload is set to a value that corresponds to a trigger having been triggered. When the control module 301 in the Notification Service 300 detects that the Trigger bit of the message payload is set to the trigger value (for example Trigger=1 for “true”), then the control module 301 accesses the subscriber record 360 associated with the SSDAD device ID 361 of the SSDAD 105 in the subscriber database 305, and for each notification recipient handle 364 a, 364 b, 364 n with the SSDAD device ID 361, it formats a notification message appropriate for corresponding delivery service (e.g., a human readable text or email message), and sends the formatted notification message to a delivery address indicated by the handle using corresponding delivery service, as indicated in fields 364 a, 364 b, 364 n of record 360.
FIG. 12 is a block diagram of a sensor alert notification device (SAND) 400. In this embodiment, the SAND 400 includes a microprocessor 401, computer readable storage memory 402, cellular modem 403 with antenna 404, SIM 405, battery supply 407 and power switch 408. Additionally, the SAND 400 may include one or more sensors 406 a, 406 b, 406 n (collectively 406) that sense, and/or sense and process, an environment, to respectively detect a respective predefined condition and to alert the controller 401 upon detection of such predefined condition. Sensors 406 may be directly electrically coupled to the controller 401. For example, each of sensors 406 may have a corresponding alert output that electrically connects, directly or indirectly through additional circuitry, to one or more interrupt ports of the controller 401. Corresponding interrupt service routines within the program code of the controller 401 (which may be stored in memory 402) implement control logic for processing the alert, decoding the alert (if necessary), determining whether to send an alert message to an external Notification Service (such as Notification Service 123) in cooperation with the cellular modem 403 and antenna 404 over an LPWAN. In an embodiment, no sensors 406 exist on board the SAND 400. In an alternative embodiment, one or more sensors 406 are implemented on board the SAND 400.
In an embodiment, SAND 400 includes a low-power (relatively) long-range (LPLR) transceiver 409, such as a 433 MHz transceiver, equipped with an antenna 410. With reference to FIG. 13, in an embodiment where SAND 400 is equipped with a LPLR transceiver 409, SAND transceiver 409 listens for signals from remote sensors 421 a, 421 b, 421 m (collectively 421) located in the proximate environment 420 where SAND 400 can detect, receive and process the LPLR signal(s) transmitted over the LPLR antenna(s) from the sensor(s) 421. In an embodiment, the SAND LPLR transceiver 409 (FIG. 12) is a receiver only, and only receives signals from the remote sensors 421 and does not communicate out to the remote sensors 421. The one-way signaling arrangement from sensor 421 to SAND 400 allows the SAND 400 to enter a power saving mode (PSM) unless and until alerted by a sensor 421 a, 421 b, . . . , 421 m. In an embodiment, any number of remote sensors 421 a, 421 b . . . , 421 m may transmit alerts and SAND 400 may process alerts sent by any number of remote sensors 421 a, 421 b . . . , 421 m. In this way, SAND 400 can be configured to operate as a gateway for the remote sensors 406 to the Notification Service 123 for sending out alert notifications to notification recipients, whereby alert notifications contain information indicating the triggering of an alert condition from a sensor 421 a, 421 b . . . , 421 m.
FIG. 14 depicts an example high-level format of a message 430 that is transmitted by a sensor 406 a, 406 b, 406 m to a SAND 400. As illustrated, the message 430 comprises a plurality of binary bits 431 arranged in fields 432, 433, . . . , 437. Pilot Period field 432 contains to a pilot period bit pattern which transceiver 409 on SAND 400 uses to trigger the start of a potential message. Synchronization Period field 433 contains a known pattern of bit values used by the SAND 400 to synchronize the receiver with the incoming data stream. Address Field 434 contains an address associated with the sensor which the sensor 421 broadcasts and which is recognizable by the SAND 400 to decode which sensor 421 sent the alert. A number of Data fields 435, 436, 437 contain data including at least sensor identification data (such as its serial number, the type of the sensor, and a number of status and/or control bits from which the SAND controller 401 can identify which sensor is sending the message, what its status is, and/or whether the controller 401 needs to perform any control operations (such as updating firmware, notifying of a low battery condition, etc.). Finally, message 430 includes a Post Code field 437 which indicates to transceiver 409 that the LPLR communication is complete.
In an embodiment, SAND 400 comprises a Global Navigation Satellite System receiver (and processor) 411 (such as one capable of acquiring and processing signals from the Global Positioning System (GPS), GLONASS, Galileo, Beidou and other regional satellite navigation systems 422) to determine location of the SAND 400 using time signals transmitted via satellite radio waves along a line of sight. In an embodiment, the GNSS receiver 411 is integrated into the same integrated circuit chip as the cellular modem 403. For example, in one embodiment, the cellular modem 403 and GNSS Receiver 411 are implemented using a Quectel BG96, as detailed previously. In an embodiment, the controller 401 may periodically turn on and enable the GNSS receiver 411 to acquire the current position of the SAND 400, and then turn off and/or disable the GNSS to save power.
In an embodiment, when an alert message is formulated and sent to the Notification Service 123, the controller 401 obtains the current (or most recent) geo-spatial position, or GPS coordinates, of the SAND 400 as acquired by the GNSS Receiver and processor 411, and includes the current (or most recent) location coordinates in the payload 30 of the alert message that it sends to the Notification Service 123. The Notification Service 123 may use the geo-spatial position coordinates as data input to its control logic. Alternatively, the Notification Service 123 may include the geo-spatial position coordinates in its message to notification recipients.
As previously mentioned, an important consideration in the implementation of the SSDAD or SAND and other system elements is the limited power supply available for powering the SSDAD/SAND due to its stand-alone battery power supply. In order to maximize the life of the SSDAD in the field, the SSDAD may be configured to implement several additional power saving features. In an embodiment, the controller 201 is programmed to determine whether, and how often, to send an alert message to the Notification Service when the sound detection device 206 is triggered by sound/vibration above its programmed threshold. For example, in an embodiment, an SSDAD 105/SAND 400 may be programmed to send an alert message to the Notification Service every time it is interrupted by the sound detection device 206. However, for situations where detected sound is above the programmed threshold, or the alert condition which triggers the alert remains in existence for long periods of time, SSDAD 105 may generate many alert messages that provide no additional information. In an alternative embodiment, the controller 201 may be programmed not to send an alert message to the Notification Service 107 if it has already sent an alert message within a programmed amount of time. It may further be programmed to change the rate at which it sends alert messages. For example, when the controller 201 receives a first interrupt, it may immediately send an alert message to the Notification Service 123. Upon receive of a second interrupt within a given period of time from the first interrupt, it may delay sending another alert message until a certain amount of time has passed and the condition still exists, and/or may gradually increase the delay in sending additional alert messages if it continues to receive interrupts that appear to be a result of the same condition causing the first interrupt (e.g., a prolonged sound or vibration) based on proximity in time of the interrupts.
Determination of whether to send an alert to the notification service may vary depending on the purpose and application of use of a particular SSDAD/SAND. In an embodiment, the SSDAD/SAND controller sends an alert message for every alert generated by a sensor. In an embodiment, the SSDAD/SAND controller sends an alert upon the satisfaction of one or more additional conditions (for example, a certain amount of time must pass before sending a next alert). In an embodiment, once an alert is sent, if the sound signal or other sensed condition continues without cease for a certain duration of time, the SSDAD/SAND sends only one or a small few alerts. If the sound signal sound signal or other sensed condition ceases, in an embodiment, the SSDAD/SAND may send another alert indicating cessation of the sound signal. In general, the SSDAD/SAND controller may be programmed to send as many or few alert messages to the Notification Service as meets the requirements of the application and purpose for which the SSDAD/SAND is installed. For example, it may be sufficient to alert the notification service a single time upon receipt of a first alert by a sensor and then ignore further alerts. In a different application, it may be better to require a set number of alerts from a given sensor before alerting the notification service. In yet another application, it may be desired, once an alert message has been sent to the notification service, to send an alert upon cessation of the condition that caused the alert. In accordance with the invention, many different scenarios in the alerting scheme are feasible and contemplated for use with the SSDAD/SAND, and any exemplary embodiments described herein are not intended to be limiting.
In an embodiment, upon receiving an alert message, the Notification Service 123 decodes the alert and extracts the device identifier and alert code and/or other message information from the alert message. Depending on the specific alert code and/or other message information, the Notification Service 123 may determine whether to send a notification message to the notification recipients associated with the sending device. In an embodiment, the Notification Service 123 sends a notification message to all notification recipients for every alert message it receives from the SSDAD/SAND. In an alternative embodiment, the Notification Service 123 may process the alert code and send a notification message only under certain conditions. For example, if the Notification Service 123 determines it has received an identical alert code within a predetermined time period before the receipt of the present alert code, it may be programmed to ignore the later-received alert message from the SSDAD/SAND until the predetermined time period has passed. Alternatively, the Notification Service 123 may continue to send alert notification messages to the notification recipient(s) upon receipt of repeat alert notifications from the SSDAD/SAND, but the SSDAD/SAND controller 201/401 may increase, or gradually increase, the time between sending alerts to the Notification Service 123. In this way, notification recipients will not be overwhelmed with notification messages that alert to the same ongoing condition.
As described previously, in order to conserve battery power, the SSDAD utilizes a power saving mode (PSM) by disabling high-power-consuming features in the system. In particular, in a preferred embodiment, SSDAD 200 and/or SAND 400 disables the cellular modem upon completing a command sequence. This means that the Notification Service 123 cannot contact the SSDAD/SAND until the SSDAD/SAND is awakened by a sensor alert. In an embodiment, the SSDAD 200/SAND 400 may alternatively be programmed to send a status message, referred to as a “heartbeat”, to the Notification Service 123 on a programmed schedule. The heartbeat status message may be used to inform the Notification Service 123 that the SSDAD 200/SAND 400 is operating and is able to communicate with the Notification Service 123. The Notification Service 123 may be programmed to expect a status message from the SSDAD 200 according to programmed timing. For example, the SSDAD may send a heartbeat status message once every 12 hours or 24 hours or more (or less if desired).
The Notification Service 200 may be programmed to send a notification to the notification recipients if it expects a heartbeat status message from the SSDAD 200 and does not receive a heartbeat status message within a defined time period after missing one or more expected heartbeat status message(s). The heartbeat status message enables notification recipients to know whether the SSDAD 200 is powered on and in communication with the Notification Service 123, or whether a communication problem between the SSDAD 200 and Notification Service 123 exists. The SSDAD/SAND heartbeat can be set at a rate such that the SSAND/SAND checks in with the Notification Service once every several hours, day(s), etc. or other (potentially user-configured) period of time. Rather than checking in with the network 110 every 1.2 seconds (to let the nearest tower know where the device is), the heartbeat can be set to a much longer period of time to enable it to conserve power. The SSDAD 200 need only register with the network, then go into a standby mode and need not connect to the network 110 until it needs to send a message.
In an embodiment, the SSDAD 200 includes an optional GPS module 209 with a GPS antenna 209 a. The GPS module 209 may be implemented as a separate chip, or could be embedded within the cellular modem chip 203. For example, the Quectel BG96 Cat.M1/NB1 & EGPRS Module optionally includes a GPS receiver and GPS processing circuitry for receiving GPS data from the Global Positioning Satellite System (GPSS). The controller 201 of the SSDAD 200 may be configured to retrieve GPS coordinate data of the SSDAD 200. In an embodiment, the SSDAD 200 sends GPS coordinate data to the Notification Service 123. It may send the GPS coordinate data along with each alert message. In an alternative embodiment, the controller 201 may be programmed to track the GPS coordinate data, determine whether the SSDAD 200 has moved from a previous location, and then track the GPS coordinate data, and transmit the GPS coordinate data to the Notification Service on a programmed time basis.
In the illustrative embodiment described heretofore, the cellular network 110 is an LTE-M cellular network implemented in accordance with the Third Generation Partnership Project (3GPP) standards-based LPWAN technology, LTE-M (also known as LTE CAT-M1), which has a maximum channel bandwidth of 1.4 MHz, a maximum data rate of 1 Mbit/s, and operates in either full or half duplex mode (i.e., can transmit and receive simultaneously in full duplex mode, or can only transmit or receive at any given time in half duplex mode). In an alternative embodiment, the LPWAN could be implemented using 3GPP standards-based LPWAN technology, NB-IoT (also known as CAT-NB1 or CAT-M2), which has a maximum channel bandwidth of 180 kHz, a maximum data rate of 250 Kbit/s, and operates only in a half duplex mode. In another alternative implementation, the cellular network could be implemented according to the Global System for Mobile Communications Association (GSMA) standards-based LPWAN technology known as Extended Coverage Global System for Mobile (EC-GSM), (also called EC-GSM-IOT), which also operates in the licensed spectrum (on the 900 MHz and 1.8 GHz frequency bands) and implements EC-GSM protocols utilizing the existing GSM networks and GSM cellular to Internet infrastructure. Table 1 summarizes some of the main specifications for each of the LTE CAT-M1, CAT-NB1 and EC-GSM-IoT standards.

TABLE 1

CAT-M1	NBIoT	EC-GSM-IoT

Deployment	LTE	LTE	GSM
Coverage	155.7 dB	164 dB	164 db, with 33 dBm
			power class, 154 dB
			with 23 dBm power
			class
Downlink	OFDMA,	OFDMA	TDMA/FDMA, GMSK
	15 KHz tone spacing	15 KHz tone spacing	and 8PSK, 1Rx
	Turbo Code	1Rx
	16 QAM 1Rx
Uplink	SC-FDMA	SCFDMA	TDMA/FDMA, GMSK
	15 KHz tone spacing	15 KHz tone spacing	and 8PSK (optional)
	Turbo code, 16QAM	Turbo code
Bandwidth	1.08 MHz	180 KHz	200 kHz per channel,
			typical system
			bandwidth of 2.4 MHz
Peak rate	DL and UL: 1 Mbps	DL: 50 kbps	DL and UL: 70 kbps
(DL/UL)		UL: 50 Kbps for	(GMSK) using 4
		multi-tone, 20 Kpbs	timeslots
		for single tone
Duplexing	FD & HD (type B),	HD (type B), FDD	HD, FDD
	FDD & TDD
Power	PSM, ext. I-DRX,	PSM, ext I-DRX,	PSM, ext. I-DRX
saving	C-DRX	C-DRX
Power	23 dBm	23 dBm	33 dBm
class	20 dBm		23 dBm

It is to be noted that commercial networks implemented in accordance with any of the LTE CAT-M1, CAT-NB1 and EC-GSM-IoT standards operate in the licensed spectrum of the radio-frequency spectrum (meaning that the frequency bands on which they operate are regulated by governmental regulatory bodies). Operation within the licensed spectrum requires operators to obtain a license or permit from a regulatory authority and to adhere to a set of technical, operational and behavioral rules, having the effect of potentially offering a higher quality of service (QOS) for delivery of communications between the SSDAD 105 and the Notification Service 123 than may otherwise be obtained using networks operating in the unlicensed spectrum. It may therefore be advantageous to use such an available cellular network to communicate SSDAD alert messages from the SSDAD 105 to the Notification Service 107. However, it is to be understood that in other embodiments, it may be suitable or advantageous to use a LPWA network operating in an unlicensed frequency band of the radiofrequency spectrum. Examples of such networks may include, but are not limited to, LoRa, SigFox, etc. Furthermore, while a preferred embodiment of the SSDAD is battery powered and therefore to conserve power connects to the Notification Service via a LPWAN, in alternative embodiments where power consumption is not at issue for the SSDAD, the SSDAD may be implemented using a transmission module that allows it to transmit its alert messages via any wireless or wired network (including, but not limited to, LPWANs, LANs, WANs, WiFi Access Points, etc.) using an appropriate corresponding transmission protocol. For example, if the SSDAD 105 is not positioned in a remote location and has access to a Wi-Fi Access Point, the SSDAD 105 could be configured to include a WiFi transmission module and to send its alert messages to the Notification Service by connecting to the Internet via a local WiFi Access Point. Similarly, if WiFi is not available but a cellular service (that is not an LPWAN) is available, the SSDAD 5 could include transmission module that can communicate with the available cellular service (which may not be an LPWAN) and could then transmit its alert messages via that cellular service.
In an embodiment, the SAND 400 further includes a low-power low- to mid-range transceiver or receiver (collectively, referred to as “transceiver”) which can receive messages from one or more remote sensors. In an embodiment, the transceiver comprises a 433 MHz transceiver that listens for messages sent from remote sensor devices within distance of its operational range (e.g., within approximately 100 meters). In an embodiment, to conserve power, the transceiver is active or “wakes up” periodically (for example, every second or every few seconds) to listen for a message from a remote sensor unit. The remote sensor unit may be configured to transmit for a few times longer than the period the transceiver wake period, so that the SSDAD is guaranteed to be in a wake period at least once during the sensor transmission period. In order to conserve battery life, both the transceiver of the SSDAD and the sensor unit automatically go into a PSM state when not transmitting or when not in a wake period. Further to conserve power, the transceiver component of the SSDAD and the components of the sensor unit each comprises a low-power electronic component.
By way of example and not limitation, in an embodiment, the sensor unit may comprise one, or a combination of, the following sensors: an accelerometer, a microphone, a passive infrared (PIR) sensor, a reed switch, a camera, a liquid level sensor, a charge sensor, a load sensor, a voltage sensor, a resistance sensor, a capacitance sensor, a thermo sensor, a temperature sensor, a humidity sensor, a flex sensor, a pressure sensor, a chemical composition sensor, a light sensor, a UV Index sensor, a sound sensor, a wind sensor, a positioning sensor, a moisture sensor, etc. In an embodiment, a system includes a plurality of sensor units positioned in proximity (within receiver range) to the transceiver of a SAND. Such SAND includes program instructions to listen for sensor event alerts from sensor units 421 within its receiving range, identify the sensor sending a sensor event alert, decode such sensor event alert(s) and send one or more message alert(s) to the Notification Service to alert notification recipients to the occurrence of the sensor event using one of the designated notification delivery methods associated with the SSDAD/SAND.
The SSDAD/SAND may be used in a plurality of applications. In an embodiment, the SSDAD may be physically attached to a door, a window, a trap, a mailbox, a trashcan, a safe, a cabinet, a portable object such as a vehicle, a boat, a bicycle, a tractor, a generator, a beehive, or any object that one desires to monitor. Vibration caused by movement, tampering, falling, interference, or other interaction with the monitored object will generate a notification message to one or more designated notification that the monitored object has been moved, tampered or interfered with, fallen, or otherwise sensed a vibration or loud sound. In an embodiment, the SSDAD may be installed with the premises of a house, a garage, a shed, a remote building, etc. Loud sound caused by smoke and/or other sound-generating alarm systems will also generate a notification message to the one or more designated notification recipients associated with the SSDAD. Monitoring in this manner can be performed without requiring an external power supply or frequent battery replacement or recharging. The low power unit can last 5-10 years using 3 conventional AAA or 2 AA batteries based on 2300 network connections (pings) at 2 pings per day.
An advantage of the systems discussed herein, and in particular with respect to the SAND system with external sensors as discussed in connection with FIGS. 13-15 is that it allows end consumers to set up a monitoring and notification system on a modular basis. That is, an end user can install a SAND 400 in an environment, and then place remote sensor units 421 of the same or different types anywhere within the signal range of the SAND 400, and receive alerts if any one of the remote sensor units alerts the SAND 400. The placement of the sensors 421 is completely up to the end user, and no sensor is required to communicate with any other sensor in the system. Sensors 421 need only transmit an alert using the LPLR protocol that is recognized by the SAND 400, and the SAND 400 will receive the alert and notify the notification service 123 to notify the notification recipients associated with the SAND 400. The modular monitoring system is easy to install because since the SAND is equipped with a self-contained power source (i.e., a battery or solar panel/inverter) and does not require a WiFi or LAN access port, the SAND and sensors can be placed anywhere, including remote locations (so long as the LPWAN provides sufficient coverage to allow the SAND to connect to the LPWAN. Modular, Do-It-Yourself simple to install and user-configurable monitoring system design, Always-On, Long-Lasting, self-contained—all these advantages over existing and prior art monitoring and notification systems.
Those of skill in the art will appreciate that the invented systems, methods and apparatuses described and illustrated herein may be implemented in software, firmware or hardware, or any suitable combination thereof. Additionally, those of skill in the art will appreciate that the methods of the invention may be implemented by a computer or microprocessor process in which instructions are executed, the instructions being stored for execution on a computer-readable medium and being executed by any suitable instruction processor. Alternative embodiments are contemplated, however, and are within the spirit and scope of the invention.
Although this preferred embodiment of the present invention has been disclosed for illustrative purposes, those skilled in the art will appreciate that various modifications, additions and substitutions are possible, without departing from the scope and spirit of the invention as disclosed in the accompanying claims. It is also possible that other benefits or uses of the currently disclosed invention will become apparent over time.

Claims

What is claimed is:

1. An electronic device, comprising:

a wireless transmitter, the wireless transmitter configured to transmit data on an antenna;

an electronic sound detection device which generates one or more output signals in response to sound sensed from a sound signal generated by a sound alarm device;

electronic memory which stores an identifier, the identifier associated with the electronic sound detection device and with a registered user of a notification service executing on a remote server;

a controller coupled to the sound detection device, the memory, and the wireless transmitter, wherein, in response to the one or more output signals, the controller encodes the identifier into a notification message and transmits the notification message, via the transmitter, to the notification service, and wherein upon receipt of the notification message by the notification service, the notification message triggers the notification service to send an electronic notification message to an electronic device associated with the identifier, the notification message notifying a user of the electronic device that the sound alarm device is sounding.

2. The electronic device of claim 1, wherein the user notification message comprises at least one of an email, an SMS text message, an instant message (IM), an in-app push notification, an automated voicemail, a webpage popup message, an update to a notification service dashboard, an update to a notification service database.

3. The electronic device of claim 1, wherein the sound detection device comprises an accelerometer.

4. The electronic device of claim 1, wherein the sound detector comprises a microphone.

5. The electronic device of claim 1, wherein the sound signal is characterized by a predetermined sound signature, and the electronic device further comprising a signal processor, coupled to the sound detection device and the controller, which processes the detected sound and generates a signature match signal indicative of whether the detected sound is sourced by a sound signal characterized by the predetermined sound signature, wherein the controller is responsive to the one or more output signals and the signature match signal to transmit the notification message only when the signature match signal indicates that the detected sounds are sourced by a sound signal characterized by the predetermined sound signature.

6. The electronic device of claim 1, wherein the wireless transmitter is configured to communicate over a low power wide area network (LPWAN).

7. The electronic device of claim 1, wherein the notification service executes on a remote server and generates the user notification message and sends the user notification message to the user device via the Internet.

8. The electronic device of claim 1, wherein the user notification message comprises at least one of an email, an SMS text message, an instant message (IM), an in-app push notification, an automated voicemail.