Core Packet Standard (CPS) V1.0

This document defines the structural standard for data packets sent by devices developed under Core Packet Standard (CPS) V1.0 to backend systems. The purpose of standardization is not merely to transmit data, but to ensure that devices with different hardware classes, different communication capabilities, and different operational conditions can reliably operate under a common data model. For multiple device families to be managed together on the same backend, for packets to be parsed through a single contract, and for field data to be processable over extended periods, the data packet must have an open, clean, and consistent framework.

This need is particularly pronounced in IoT devices that are resource-constrained, often battery-backed, and sometimes operate under intermittent connectivity conditions. An overly complex packet structure increases firmware costs, enlarges transmission overhead, and makes backend data processing fragile. Conversely, an overly lean but unguided structure leads to the breakdown of the common model as device diversity grows, the same data family being represented in different forms, and the weakening of operational observability. The goal of this standard is to establish a balanced structure between these two extremes: a minimum mandatory core, controlled optional extension, and a long-term manageable data backbone.

Structural Principles​

In this standard, the packet format is specified as JSON. The JSON choice is retained because it provides ease of implementation on both device and backend sides, debugging visibility, and readability advantages in multiple integration scenarios. However, the textual transmission cost of JSON is balanced by keeping packet content controlled; therefore, the mandatory field set is kept as small as possible, and additional fields are optionally structured based on need. JSON packets are generated on the device without whitespace.

The packet structure consists of three main segments: Info, Device, and Payload. This separation allows the contextual identity of the packet, the device's operational state at the moment of production, and the application-specific primary data to be distinguished from each other. This simplifies processing flows on the backend side and keeps the extension of the data model within defined boundaries.

The fundamental principle in the representation model is to use a single, consistent representation for the same data family. It is not acceptable for the same semantic content to be carried with individual fields in one device, as an array in another device, and with different names in another firmware version. For this reason, a structure that appears free-form but is not uncontrolled is adopted on the payload side; the flat object approach is maintained, but the representation type of variables is defined in advance. This achieves a balanced model between flexibility and data governance.

General Packet Structure​

Each data packet is carried as a JSON object and consists of the following three main segments:

{
  "Info": {},
  "Device": {},
  "Payload": {}
}

In this structure, Info carries the packet's identity, production time, and transmission context. Device contains telemetry related to the device's operational state at the moment data was produced. Payload carries application-specific measurement, event, or process data. This separation of sections makes it possible to carry both observability and functional data within a single packet.

Info Segment​

The Info segment forms the minimum contextual backbone of every packet. Understanding which device produced a packet, at what moment, and within which production sequence is provided through this segment on the backend side. Therefore, Info is not merely an auxiliary section of metadata, but the mandatory core segment for packet interpretation.

Command​

Command expresses the type or functional reason for transmission of the packet and is one of the mandatory fields of the Info segment. In this version, it only takes values defined in the table below.

TimeStamp​

TimeStamp represents the time the device had at the moment it created the packet and is one of the mandatory fields of the Info segment. This time information is read from the RTC source synchronized within the device and via GSM. Therefore, the meaning of the field is not the time of server arrival, but the moment the packet was produced on the device. This distinction is critically important in scenarios such as store-and-forward, delayed transmission, or bulk transmission after connection loss.

In this version, the TimeStamp field is carried in the following format:

YYYY-MM-DDTHH:mm:ss

Example:

2026-03-26T20:10:00

This field represents the device's local time. It does not contain UTC indicator (Z) or timezone offset. When interpreting this field on the backend side, local time semantics without timezone should be preserved.

ID​

ID is the HEX string representation of DS28C-based 48-bit ID + 8-bit CRC data and is one of the mandatory fields of the Info segment. This field is a lightweight, portable, and easily processable backend-side representation of the device identity. No additional sub-fields or secondary identity structures for ID are defined in this document.

Seq​

Seq is not a successful transmission counter; it expresses the device's data production sequence and is one of the mandatory fields of the Info segment. It increments with each new packet production and may reset after a device reset. This definition is necessary to avoid confusing retransmission with new data production, for more accurate interpretation of missing or duplicate records, and for preserving relative data order.

IMEI / ICCID / Firmware​

IMEI, ICCID, and Firmware fields are optional complementary fields; they are not part of the mandatory core. These are not telemetry values repeated in every packet, but supplementary inventory information sent when needed. It is sufficient to transmit them during situations such as initial registration, modem or SIM replacement, firmware update, or inventory refresh needs. This preference enables keeping backend inventory up-to-date without increasing packet size.

Info Field Dictionary​

This section normatively fixes the transport contract for fields in the Info segment. Unless otherwise specified, the following type, format, and absence behaviors must be preserved.

If a counter overflow occurs in the Seq field, the value returns to 0 with mod $2^{32}$ behavior. It is acceptable for Seq to start from 0 after a device restart.

Command Production Rules​

The Command field must not be filled with free interpretation. Only a single Command value must be selected for the same root event.

1. Online must be produced when a communication session is successfully established or re-established while the device is operational.
2. Offline must be produced before shutdown or exit from access if the device can gracefully terminate the connection. Failure to produce it in situations such as sudden power loss is not considered a protocol violation.
3. Timed must be used for timer-based normal periodic transmissions.
4. Timed_Tiny must be used for timer-based reduced-content transmissions. Both Timed and Timed_Tiny must not be produced for the same time slot.
5. Interrupt must be used when instantaneous data is produced by a hardware or software interrupt trigger outside of the periodic flow.
6. Event must be used for state changes that do not reach alarm level but need to be recorded.
7. Alarm must be used in conditions requiring critical threshold exceedance, fault, or emergency intervention.
8. If the same root event satisfies both Event and Alarm conditions, Alarm must be selected.
9. If the same root event satisfies both periodic transmission and interrupt-based transmission conditions, the actual cause of the event — Interrupt, Event, or Alarm — must be selected instead of the periodic command.

Device Segment​

The Device segment carries the device's operational state at the moment data was produced. This segment enables the device to be observed not only as an endpoint that produces measurements, but also as a physical system exposed to field conditions. Particularly power status and communication quality have a direct impact on data reliability and maintenance requirements, making the Device segment critically important for operational observability.

This segment is modeled under two sub-sections:

• Power
• IoT

{
  "Device": {
    "Power": {},
    "IoT": {}
  }
}

This separation is preserved. Fields belonging to the power side and fields belonging to the communication context are not mixed together; however, the same fundamental approach applies to both sub-sections: minimum mandatory core and controlled optional extension.

Device.Power Segment​

Since this product family consists of battery-backed devices, power status is treated not as auxiliary information, but as core operational context that directly affects device behavior. Nonetheless, carrying every possible power metric in every packet is not preferred. This approach unnecessarily increases packet size, conflicts with low energy targets, and generates unnecessary transportation costs on the firmware side. For this reason, the minimum field set that provides core power visibility has been separated from additional fields that are hardware- or need-dependent.

B_IV​

B_IV is the core monitoring field for the battery side and is one of the mandatory fields of the Device.Power sub-segment.

B_AC​

B_AC is one of the core fields used in interpreting battery behavior and is mandatory in the Device.Power sub-segment.

B_CS​

B_CS is one of the core fields carrying charge or general power status context and is mandatory in the Device.Power sub-segment.

B_IC​

B_IC is one of the optional fields that can be used to carry need-based additional power telemetry.

B_FC​

B_FC is one of the optional fields reserved for need-based additional power telemetry.

B_SOC​

B_SOC is one of the optional fields that can be used to carry interpreted or derived capacity/level information.

B_T​

B_T is one of the optional fields that can be sent if battery temperature is available.

Device.IoT Segment​

The Device.IoT sub-segment carries the device's communication context. Although current systems mainly operate on GSM-based connectivity, the standard is not locked to only today's carrier structure. The communication field set is kept open for extension so that the same data model can potentially cover different access technologies in the future. For this reason, communication context is represented in the packet, but information that repeats the device type and can already be known on the backend side is not included in the mandatory core.

RSSI​

RSSI is the basic field used to practically monitor communication quality and is one of the mandatory fields of the Device.IoT sub-segment.

WDS​

WDS is one of the optional fields that can be used to carry supplementary information related to communication context.

ConnTime​

ConnTime is one of the optional fields that can be used to carry connection duration or connection establishment context.

MCC​

MCC is one of the optional fields carrying cellular network information.

MNC​

MNC is one of the optional fields carrying cellular network information.

TAC​

TAC is one of the optional fields carrying cell-specific access area information.

Cell_ID​

Cell_ID is one of the optional fields carrying the cellular cell identifier.

Device Core Field Dictionary​

This section normatively fixes the transport contract for fields used for core monitoring in the Device segment. The following semantic, unit, and range definitions must be preserved across all firmware versions within the same device family.

When an out-of-range value is produced, the transmitting device must not silently clip the field; the relevant packet must be rejected or the device must generate an error record. This behavior must be observable on the firmware side.

Payload Segment​

The Payload segment carries the application-specific primary data. This section is intentionally designed to be dynamic and is not divided into fixed sub-segments. The fundamental purpose is to carry the measurement, event, or process data produced by the device in a flat and lightweight structure.

{
  "Payload": {
    "PCB_T": 27.125,
    "VRMS": [229.841, 228.992, 230.104]
  }
}

All fields in this segment are optional; the functional content of the packet may vary depending on device type and transmission scenario. However, the structure is not entirely unguided. Which variables are carried under which names can be managed through the variables table on the backend side. The decision not to divide the Payload into additional inner layers is intentional; additional internal segments in most cases produce transmission costs, firmware complexity, and backend mapping overhead rather than semantic gains. For resource-constrained devices, the flat key-value model offers a more sustainable backbone.

When sending data over IoT, JSON packets must be transmitted in whitespace-free / minified format. That is, production packets must be carried in the most compact JSON form without line breaks, indentation, or readability-oriented whitespace. The examples shown in the document are for readability; the actual transmission format on the device side must be the compressed/whitespace-free equivalent of these. This is specifically to reduce data costs in GSM-based systems, prevent unnecessary byte consumption, and maintain field reliability. In practical experience, it is preferred that the packet size does not exceed the approximately 1024 byte limit.

Payload values will in practice mostly be numeric, and the current expectation is that a significant portion of values can be carried in float format with meaningful precision up to three decimal places in most scenarios. This statement is not a strict mandatory precision standard, but a practical representation approach in application.

Packet Budget​

This standard must be evaluated not only in terms of semantic correctness, but also in terms of field-side transport reliability. Especially in GSM-based devices, packet size growth has a direct impact on transmission time, cost, modem stability, and queue management.

For this reason, an approximate 1024 byte safe operating limit should be used as reference in packet design. The whitespace-free/minified transmission rule is normatively defined in the Payload Segment section.

Calculation Method​

Byte calculations in this document are evaluated with the following assumptions:

• packets are sent as minified JSON,
• UTF-8 is used,
• field names are carried with the names in this document,
• JSON key names, quotation marks, colons, commas, and brackets are included in calculations,
• numeric fields are typically carried as plain text in float or int format.

The purpose of these calculations is not to perform exact bit-level compression calculations, but to create an engineering byte budget to guide design decisions.

Reference Minimum Packet​

The following minimum packet is calculated based on the minified JSON representation of the core fields defined in this version:

{"Info":{"Command":"Timed","TimeStamp":"2026-03-26T20:10:00","ID":"00112233445566","Seq":1842},"Device":{"Power":{"B_IV":3.981,"B_AC":0.124,"B_CS":1},"IoT":{"RSSI":-79}},"Payload":{}}

The total size of this packet is approximately 183 bytes.

This shows that the core structure is well below the 1024 byte limit and that the main growth will come from the Payload side.

If packet size is expected to exceed the safe operating limit, the device should follow the priority order below:

1. Optional inventory fields must be removed.
2. Optional Device fields must be removed.
3. Low-priority Payload fields must be trimmed according to device family rules.
4. If mandatory core fields cannot be preserved, the packet must not be sent and an error record must be generated on the device side.

General Byte Budget Interpretation​

In practice, the fields that grow packet size fastest are:

• long string fields (ICCID, IMEI, some identity fields),
• multi-element vectors,
• harmonic arrays,
• unnecessary repetitions of the same data family,
• carrying too many optional telemetry fields together in the same packet.

For this reason, the core strategy should be:

• Info should be kept as fixed and small as possible,
• Device should be limited to minimum health telemetry,
• Payload should expand as needed, but the representation format should be carefully selected per data family.

Per-Variable Byte Assessment​

In this document, Min Byte, Typical Byte, and Max Byte values are given for variables with the following meanings:

• Min Byte: approximate space the field will occupy in the packet with the short/lower bound representation
• Typical Byte: approximate space based on the normal usage example expected in the field
• Max Byte: approximate space with the long representation that can be considered practically meaningful

These calculations show the actual JSON cost of the variable within the packet; that is, they include not only the value itself, but also the key name and JSON syntax.

Payload Variable Structures​

The Payload segment is not treated as a free-form field set; it is evaluated with a controlled variable type system. The purpose of this is to prevent the same data family from being represented in random formats across different devices or different firmware versions. Once a data family is defined, the representation model must remain consistent for that family.

In this version, the following basic type family is defined:

scalar​

scalar represents a single physical or logical value.

{
  "Payload": {
    "PCB_T": 27.125
  }
}

phase_vector​

phase_vector is the phase-based representation of the same data family. The representation order is fixed and in this draft the example order is taken as [R,S,T].

Vector transport example:

{
  "Payload": {
    "VRMS": [229.841, 228.992, 230.104]
  }
}

Alternative representations for a data family can be designed; however, in production only the representation canonically defined for that family in the variable catalog must be used. The following example is an alternative schema representation and can only be used if the relevant variable family is fixed in this form:

{
  "Payload": {
    "VRMS_R": 229.841,
    "VRMS_S": 228.992,
    "VRMS_T": 230.104
  }
}

The fundamental decision in this model is:

• the same data family can appear in the same packet in only one representation format,
• that is, the VRMS vector and VRMS_R / VRMS_S / VRMS_T fields must not be carried together in the same packet.

This rule is mandatory to prevent data repetition and interpretation conflicts.

Once the canonical representation format of a variable family is defined, the same family must not be carried with a different representation in another firmware version. If a representation change is needed, this change must be managed with a new catalog revision and compatibility assessment.

harmonic_vector​

harmonic_vector is used for fixed harmonic series. For example, if the IHARM_R variable carries specific harmonic orders, these orders must be pre-defined, fixed, and mutually understood on both device and backend sides.

Example representation:

{
  "Payload": {
    "IHARM_R": [0.812, 0.441, 0.203, 0.000, 0.000]
  }
}

In this model, array length and the meaning of indices are part of the variable definition. If some harmonics are unmeasured or unavailable in the relevant packet, a separate validity mask is not defined; instead, the zero fill approach is used and missing positions are filled with 0.

stat_vector​

stat_vector carries summary statistics of a variable within a certain time window or sampling period as a fixed-order array.

In this version, the recommended fixed order is:

[instant, min, max, average, datacount]

• instant: current value at the moment the packet is produced
• min: minimum value in the relevant time window
• max: maximum value in the relevant time window
• average: average value in the relevant time window
• datacount: number of samples over which this summary was produced

Example:

{
  "Payload": {
    "PCB_T_STAT": [28.125, 27.900, 29.100, 28.430, 60]
  }
}

This type is particularly suitable for data families that carry statistical summaries. If some fields could not be produced in the relevant time window or are not calculated by that device/algorithm, the zero fill approach can be applied in this version.

custom_vector​

custom_vector is used for data families that do not fall into the standard phase, harmonic, or channel classes but still need to be represented with sorted array logic. This type should only be used when there is a genuine need and must not be treated as an uncontrolled free field.

Energy Parameters​

In this standard, the Payload segment remains flat and dynamic; however, logical variable sets can be defined for specific product families. In this version, the first defined set is the energy data set used for energy measurement devices. This set is grouped under the headings of voltage, current, power, and energy.

The purpose of this section is not merely to list variable names, but to clarify what each data family represents, in which type it is carried, and its example data format. This prevents the same fields from being used with different interpretations across different devices in the future.

Common Rules​

The following common rules apply to the energy measurement set:

• The order is fixed in all phase-based vectors: [R,S,T].
• In harmonic vectors, the axis represents the pre-fixed harmonic order defined in the variable definition.
• The zero fill approach is applied for missing or uncalculated components in harmonics.
• This section is the first defined payload set for energy measurement devices; new variable families can be added in the future while preserving the same type system.

Voltage Data​

The voltage group defines the phase-based voltage behavior, fundamental component, and harmonic content of the system.

VRMS​

VRMS carries RMS voltage values for phases.

• Data type: phase_vector
• Order: [R,S,T]
• Unit: Volt
• Example data: [220.1,224.2,221.8]
• Estimated byte budget: min ~14, typical ~26, max ~41

This field directly shows the effective voltage level of each phase in three-phase systems. How this type of field should be reduced or whether it should be kept as a single-element vector in single-phase systems can be decided separately.

FQ​

FQ carries system frequency.

• Data type: scalar
• Unit: Hertz
• Example data: 50.000
• Estimated byte budget: min ~7, typical ~12, max ~18

Frequency information is treated as a single quantity and is not broken down for separate phases in this version.

VFUND​

VFUND carries the fundamental component of voltage on a phase basis.

• Data type: phase_vector
• Order: [R,S,T]
• Unit: Volt
• Example data: [219.8,223.7,221.1]
• Estimated byte budget: min ~15, typical ~27, max ~42

This field is used to monitor the fundamental frequency component separately from the total RMS quantity.

VHARM_R, VHARM_S, VHARM_T​

These fields carry voltage harmonic series for each phase.

• Data type: harmonic_vector
• Axis example: [3,5,7,9,11]
• Unit: Volt
• Example data: [0.012,0.031,0.020,0.006,0.000]
• Estimated byte budget: min ~17, typical ~42, max ~67

Each variable belongs to a single phase. For example, VHARM_R carries the selected harmonic components of phase R in a fixed-order array. If a harmonic value is unavailable or uncalculated, the field is not removed; the zero-fill approach is maintained.

Current Data​

The current group defines phase-based load current, peak current behavior, fundamental component, and harmonic current content.

IRMS​

IRMS carries phase-based RMS current values.

• Data type: phase_vector
• Order: [R,S,T]
• Unit: Ampere
• Example data: [5.124,4.982,5.301]
• Estimated byte budget: min ~14, typical ~23, max ~38

IPEAK​

IPEAK carries peak current values for phases.

• Data type: phase_vector
• Order: [R,S,T]
• Unit: Ampere
• Example data: [7.410,7.052,7.630]
• Estimated byte budget: min ~15, typical ~24, max ~39

This field can be useful for understanding instantaneous load behavior, peak current effects, or system stresses.

IFUND​

IFUND carries the fundamental component of current on a phase basis.

• Data type: phase_vector
• Order: [R,S,T]
• Unit: Ampere
• Example data: [4.910,4.755,5.110]
• Estimated byte budget: min ~16, typical ~25, max ~40

IHARM_R, IHARM_S, IHARM_T​

These fields carry current harmonic series for each phase.

• Data type: harmonic_vector
• Axis example: [3,5,7,9,11]
• Unit: Ampere
• Example data: [0.012,0.031,0.020,0.006,0.000]
• Estimated byte budget: min ~17, typical ~42, max ~67

For example, IHARM_R carries the selected harmonic current components of phase R in a fixed array. The zero-fill approach is applied for missing or uncalculated harmonic values.

Power Data​

The power group carries phase-based active, reactive, apparent, and power factor related quantities.

P​

P carries phase-based active power values.

• Data type: phase_vector
• Order: [R,S,T]
• Unit: Watt
• Example data: [1050.220,980.114,1120.450]
• Estimated byte budget: min ~10, typical ~34, max ~52

Q​

Q carries phase-based reactive power values.

• Data type: phase_vector
• Order: [R,S,T]
• Unit: var
• Example data: [120.410,98.200,132.005]
• Estimated byte budget: min ~10, typical ~31, max ~49

S​

S carries phase-based apparent power values.

• Data type: phase_vector
• Order: [R,S,T]
• Unit: VA
• Example data: [1060.500,989.700,1132.100]
• Estimated byte budget: min ~10, typical ~34, max ~52

PF​

PF carries the total power factor on a phase basis.

• Data type: phase_vector
• Order: [R,S,T]
• Unit: -
• Example data: [0.991,0.990,0.989]
• Estimated byte budget: min ~11, typical ~20, max ~35

PFUND​

PFUND carries the power factor calculated over the fundamental component on a phase basis.

• Data type: phase_vector
• Order: [R,S,T]
• Unit: -
• Example data: [0.995,0.994,0.996]
• Estimated byte budget: min ~14, typical ~23, max ~38

QFUND​

QFUND carries the reactive power quantity corresponding to the fundamental component on a phase basis.

• Data type: phase_vector
• Order: [R,S,T]
• Unit: var
• Example data: [100.120,91.540,108.310]
• Estimated byte budget: min ~14, typical ~31, max ~49

Energy Data​

The energy group carries cumulative energy quantities on a phase basis.

AE​

AE carries the active energy quantity on a phase basis.

• Data type: phase_vector
• Order: [R,S,T]
• Unit: Wh
• Scale: decimal values are carried directly in Wh, no additional coefficient is used
• Example data: [1250.200,1198.400,1304.800]
• Estimated byte budget: min ~11, typical ~34, max ~55

RE_L​

RE_L carries the inductive reactive energy quantity on a phase basis.

• Data type: phase_vector
• Order: [R,S,T]
• Unit: varh
• Scale: decimal values are carried directly in varh, no additional coefficient is used
• Example data: [85.200,72.100,91.300]
• Estimated byte budget: min ~13, typical ~28, max ~46

RE_G​

RE_G carries the capacitive or counter-direction reactive energy quantity on a phase basis.

• Data type: phase_vector
• Order: [R,S,T]
• Unit: varh
• Scale: decimal values are carried directly in varh, no additional coefficient is used
• Example data: [12.400,10.200,14.100]
• Estimated byte budget: min ~13, typical ~28, max ~46

These fields are important for monitoring cumulative energy behavior. The unit and scale standard above for AE, RE_L, and RE_G fields is normative; a new revision decision is required if transportation with a different unit is needed.

Example Packet​

The following example is a representative example of the structure defined in this standard:

{
  "Info": {
    "Command": "Timed",
    "TimeStamp": "2026-03-26T20:10:00",
    "ID": "00112233445566",
    "Seq": 1842,
    "Firmware": "1.0.7"
  },
  "Device": {
    "Power": {
      "B_IV": 3.981,
      "B_AC": 0.124,
      "B_CS": 1,
      "B_T": 31.250
    },
    "IoT": {
      "RSSI": -79,
      "ConnTime": 12,
      "MCC": 286,
      "MNC": 1,
      "Cell_ID": 123456
    }
  },
  "Payload": {
    "PCB_T": 27.125,
    "VRMS": [229.841, 228.992, 230.104],
    "IHARM_R": [0.812, 0.441, 0.203, 0.000, 0.000]
  }
}

The numerical content in the example is given only to make the structure concrete; it is a representative example rather than a normative example.

Versioning and Backward Compatibility​

This document defines the normative version of the packet contract. In this version, no separate schema version field is carried within the packet; version management is conducted through document revision and variable catalog revision.

Versioning Policy​

1. Adding a field is considered backward compatible only if it is added as an optional field.
2. Changing the name, type, meaning, order, or unit of an existing field is considered a backward-incompatible change.
3. Changing the index meaning of a phase_vector, harmonic_vector, stat_vector, or custom_vector field is considered a backward-incompatible change.
4. Adding a new Command value is considered a backward-incompatible change if receiver systems do not support safely rejecting or ignoring this value.

Receiver and Transmitter Rules​

1. The transmitter must produce all fields defined as mandatory in this document without omission.
2. The receiver should be able to ignore unknown optional fields without rejecting the packet, provided the defined core segments are preserved.
3. The receiver must consider packets with missing mandatory fields or type rule violations as invalid.
4. If a backward-incompatible change is needed for the same device family, a new document revision must be accompanied by a separately defined backend and firmware migration plan.