PERS Device Communication Protocol: TCP/IP, API and SOS Event Integration

When an elderly user presses the SOS button, the location data must be transmitted accurately to the monitoring platform along with the device ID, timestamp, and other metadata. In some cases, messaging may be misinterpreted, or not sent at all, which interrupts the process of responding to the user's call for help.

For telecare providers and OEM/ODM buyers, JiAi has a PERS Device Communication Protocol, explaining how emergency wearables communicate with servers, APIs, and monitoring systems.

We understand hardware connectivity is only part of the equation. Successfully integrating a PERS server also requires agreed-upon message formats, acknowledgement mechanisms, and control frames. Additionally, firmware and software must also be compatible.

This document details some of the hurdles of reliable telecare device data communications, and some solutions.

1. What Is a PERS Device Communication Protocol?

A PERS communication protocol defines how a Personal Emergency Response System (PERS) device, or its receiving platform, exchanges information.

The Messaging Fields of a PERS communication protocol may include (but are not limited to) the following:

•Device ID: Which device/account is sending the message?

•Event type: Is the message indicating an SOS, location, or battery event?

•Message format: What is the total size of the message, where does it begin and end?

•Acknowledgement: Was the message sent successfully?

•Retry mechanism: How is a message resent if it is not successfully sent?

•Controls: Which commands can be sent to the device, what is the response of the device?

LTE facilitates the connection, and the PERS Device Communication Protocols describe how the application data is processed and structured.

2. TCP/IP vs API: Which Communication Architecture Works Better?

The emergency alert communication protocol used, is based on the customer's server infrastructure, the devices' firmware and the required integration.

Feature	Direct TCP/IP	HTTP/API Integration
Communication path	Device to designated server	Device to HTTP server or cloud-to-cloud
Data format	Defined binary or text protocol	Often JSON or another agreed format
Connection model	Persistent or reconnecting TCP session	Request-response or webhook-based
Integration requirements	Socket server and protocol parser	API endpoints and authentication
Main consideration	Connection management and message framing	API availability and delivery semantics
Typical application	Custom telecare platforms	Cloud-connected monitoring services

Direct TCP/IP Telecare Device Integration

A TCP/IP telecare device can communicate directly with a customer-designated server when supported by its firmware.

Important requirements include:

•Configurable server IP address or domain and port.

•Message framing and device authentication.

•Application-level SOS acknowledgements.

•Connection timeout and reconnection behavior.

Technical note: TCP ensures ordered delivery of bytes within an established connection, but does not confirm that an SOS event has been processed by the monitoring application.

PERS Device API Integration

A PERS device API may support communication between a manufacturer's cloud and a customer's platform or, where supported, between the wearable and an HTTP endpoint.

Buyers should confirm whether the integration is device-to-server or server-to-server. These architectures have different security, hosting, and maintenance responsibilities.

3. SOS Event Data Format: Required Fields

In order to aid monitoring platforms to extract emergency information in an unambiguous manner, uniform SOS event data format is required.

Data field	Purpose	Integration consideration
Device ID	Identifies wearable	Must match registered subscriber
Event ID	Identifies unique alarm	Supports duplicate detection
Event type	SOS, low battery, location alert	Requires agreed event codes
Timestamp	Time of event occurrence	Prefer UTC
GPS coordinates	Reports location	Include location age or validity
Battery level	Remaining battery capacity	Define units, range
Firmware version	Build of software	Supports troubleshooting

 The event specification should also describe optional fields, null values, encoding, message size limits and protocol version.

JiAi suggests confirming the SOS event data format before adjusting firmware. The field structure and field order depends on agreed protocol and selected device.

4. How Can PERS Devices Handle Communication Failures?

Reliable telecare device data transmission requires application-level error handling.

Acknowledgements and Retransmission

An emergency event may reach the server even when its acknowledgement is lost.

The PERS Device Communication Protocol must cover the following:

•ACK Mechanism: Process to indicate that the server has accepted the message.

•Retry Interval: The time device will wait to try transmitting the message again.

•Duplicate Handling: How device processes duplicate events with the use of unique IDs.

•Buffering: Ability of the device to store unsent events.

•Reconnection: Resuming the transmission after a connection has been restored.

Retrying a transmission of an event should balance alarm urgency and battery consumption, taking into account the availability of the network.

No communication protocol can guarantee the delivery of messages if the device is powered off or if there is no connectivity to the network.

5. Heartbeats, Status Reporting and Time Synchronization

Reports of status should include timestamps to support time synchronization.

•A PERS communication protocol may include periodic status messages to support the telecare platform to monitor the availability of a PERS device.

•The reported parameters may include battery status and charge, signal strength of the cellular connection, last successful communication timestamp, and device operating status.

•Heartbeats and reports should be configurable to minimize cellular data usage and battery life.

•Out-of-order and delayed events may occur and should be handled appropriately by the communication protocol.

6. Security Requirements for PERS Server Integration

Depending on the level of protection required, various forms of encryption may be used.

The communication protocol should be configurable to enable the PERS server to select the required level of protection.

A TCP connection is not encrypted. Security features must be confirmed and tested on the actual hardware, firmware, and server implementation.

7. Remote Configuration, OTA Updates and Protocol Versioning

For large deployments, PERS Device Communication Protocol customization may extend beyond SOS reporting.

Remote Configuration

Variables configurable via remote communication may vary by firmware support and include:

•The server address and the communication port

•Reporting intervals for heartbeats and location

•Settings for emergency contact

Other variables of interest may include parameters of the connected networks and devices.

Commands should include authorization, validation, execution and failure statuses.

OTA Firmware and Version Control

Firmware updates should support:

•Integrity and authenticity verification of firmware

•Interrupted update recovery

•Version compatibility and rollback

•Protocol documentations and change logs

Of particular interest is the backward compatibility of firmware when several devices on the same fleet run different firmware versions.

8. PERS Communication Protocol Integration Testing Checklist

Prior to large scale production, telecare operators must validate the complete integration of the PERS server.

Test scenario	Expected verification
Device registration	Correct device registration
SOS activation	Correct event upload and parsing
Server acknowledgment	Accepted event recognized by device
Network interruption	Defined buffering and retry
Duplicate transmission	No extra and unintended duplicate alarms
Server down	Defined timeout and recovery
Remote configuration	Config commands successfully executed
Firmware version	Correct operation of the supported firmware versions

Additional test cases should be devised to cover unsupported or invalid messages, low battery and cell signal, and device reconnection.

Different test cases should be made to test voice calling if the feature is available.

9. JiAi OEM/ODM PERS Device Protocol Customization

JiAi manufactures 4G elderly smart watches, SOS wrist bands and other telecare products for B2B.

Depending on the model and firmware selected, our engineering team can assess:

•Requirements of TCP/IP based telecare devices communication.

•Integration of PERS device API/platform.

•Definitions of SOS events and reporting parameters.

•Firmware/device configuration.

• Integration of the protocols and test of the device.

For a technical evaluation, it is requested that buyers disclose their server architecture, the event format, the authentication mechanisms, the expected volume of deployment, and the acceptance criteria.

Specific models and firmware will determine the extent to which customizations and support for a given protocol are available.

Conclusion

A reliable PERS Device Communication Protocol involves more than connecting a wearable to a server. Message structures, application acknowledgements, retransmission logic, encryption, and firmware compatibility all influence system integration.

For telecare providers, defining these requirements early can simplify PERS server integration, reduce deployment risks, and support more consistent emergency alert processing.

FAQs

Q1. What PERS device communication protocols does JiAi support?

JiAi can evaluate TCP/IP communication, API integration, and customized data protocols for its 4G PERS devices. Actual protocol support depends on the selected hardware model and firmware version.

Q2. Can JiAi PERS devices connect directly to our own server?

JiAi can assess direct PERS server integration using customer-defined server addresses, ports, and communication requirements. Direct TCP/IP connectivity must be confirmed for the selected device.

Q3. Does JiAi provide a PERS device API for third-party platforms?

JiAi can evaluate PERS device API integration for third-party telecare platforms. API availability, documentation, authentication methods, and supported functions depend on the project configuration.

Q4. Can JiAi customize the SOS event data format?

Yes, JiAi can assess customization of the SOS event data format, including device ID, event type, timestamp, GPS location, and battery status. Supported fields and formats require firmware evaluation.

Q5. How do JiAi PERS devices handle failed SOS transmissions?

Depending on firmware capabilities, JiAi can evaluate acknowledgement, retransmission, reconnection, and offline buffering mechanisms. Retry behavior and delivery confirmation should be defined during protocol integration.