NESOOFGEMDESNZ
feed

EDL Message Interface Specification V8

NESO·guidance·MEDIUM·13 Apr 2026·source document

Summary

NESO has published Issue 8 of the EDL Message Interface Specification, the protocol Balancing Service Providers use to receive dispatch instructions and submit dynamic parameters. The update implements Grid Code modification GC0166, adding two new submission message types: Maximum Delivery Offer (MDO) and Maximum Delivery Bid (MDB), plus decimal-place precision for MWh values. References to BOAR and Replacement Reserve have been removed.

Why it matters

MDO/MDB lets BSPs declare energy-limited delivery constraints directly in EDL rather than relying on workarounds, which matters for batteries and other duration-limited units bidding into the Balancing Mechanism. It is a plumbing fix that makes the BM marginally friendlier to storage, not a structural reform of dispatch economics.

Key facts

  • Issue 8 dated 13 April 2026, reference CT24.13.0013
  • Implements Grid Code modification GC0166
  • Adds Maximum Delivery Offer (MDO) and Maximum Delivery Bid (MDB) submission message types
  • MWh fields support decimal precision (±nnnn.ddd)
  • Removed references to BOAR and Replacement Reserve
  • Applies to any BSP participating in BM, RR and Ancillary Services markets for BMUs

Timeline

Effective date13 Apr 2026

Areas affected

wholesale marketstorageflexibilitygenerators

Memo

What this is about

NESO has released Issue 8 of the EDL Message Interface Specification, the protocol document that governs how Balancing Service Providers communicate with the control room. EDL — Electronic Dispatch Logging — is the pipe through which NESO sends dispatch instructions to generators and storage operators, and through which those operators redeclare their dynamic parameters back to NESO. Every BMU that participates in the Balancing Mechanism needs an EDL link. This update implements Grid Code modification GC0166.

The headline change is two new submission message types: Maximum Delivery Offer (MDO) and Maximum Delivery Bid (MDB). These let a BSP declare the maximum energy volume (in MWh) it can deliver against offers or bids over a given time window. Until now, the BM's dynamic parameters described power limits (MW) and ramp rates, but had no native way to express energy limits — the constraint that matters most for batteries, pumped hydro, and any other duration-limited asset. Operators have been working around this gap. GC0166 fills it.

Key points

Two new parameters: MDO and MDB. A BSP can now submit a Maximum Delivery Offer (the most energy it can deliver if called to increase output) and a Maximum Delivery Bid (the most energy it can deliver if called to decrease output / import). Each message specifies a time window (from/to) and MWh values at each boundary. This gives the control room direct visibility of energy-limited constraints rather than inferring them from MW profiles and assumed durations.

Decimal precision for MWh values. The MDO/MDB fields accept up to three decimal places (±nnnn.ddd), a level of granularity not available in the older MW-denominated parameters. For a 50 MW / 1-hour battery, the difference between 49.5 MWh and 50.0 MWh of remaining headroom is operationally meaningful. The existing MEL/MIL submissions remain integer MW only.

BOAR and Replacement Reserve removed. Issue 8 strips out references to the BOAR instruction type (Bid-Offer Acceptance for Replacement Reserve) and the RR market generally. These were added in Issue 5 back in 2018 when GB was expected to participate in the EU's Replacement Reserve market. That never happened. The cleanup is overdue housekeeping — removing dead code from a protocol spec that dates back to December 1999.

Everything else unchanged. The core message structure — ASCII text strings with prefix, header, and data parts, delimited by spaces and terminated with `^` — remains identical. Control messages, BOA instructions, voltage/MVAR instructions, pumped storage instructions, and all existing submission types (MEL, MIL, RUR, RDR, NDZ, NTO, NTB, MZT, MNZT, SEL, SIL) are untouched. The version number stays at 2.1. The new MDO/MDB messages slot into the existing submission framework with their own error code class (E).

What this means for storage. The BM was designed in 1999 for thermal plant. Its dynamic parameter set assumes units that can sustain output indefinitely once dispatched. A battery cannot. Before GC0166, a storage operator's options were to either (a) manually redeclare MEL downward as state of charge depleted, which is reactive and imprecise, or (b) set conservative offer volumes that understate the asset's real capability. MDO/MDB gives the control room a forward-looking energy constraint, which in principle allows NESO to dispatch storage more efficiently — calling on a battery when its remaining energy is most valuable rather than discovering mid-dispatch that it is about to hit empty. Whether NESO's control room systems actually use this information well is a separate question, but the protocol now carries the data.

Not a market redesign. This does not change settlement, pricing, or how the BM stacks bids and offers. It does not give storage a different commercial position. It is a dispatch communication improvement — better information flow between the asset and the control room. The commercial incentives in the BM remain unchanged. A battery still faces the same spread economics, the same imbalance risk, and the same lack of a long-duration value signal. MDO/MDB makes the plumbing slightly less hostile to duration-limited assets. It does not fix the economics.

What happens next

GC0166 has completed its Grid Code technical consultation. Issue 8 is the final spec. BSPs and their EDL vendors now need to implement the new message types in their communication stacks. NESO will need to update its own control room systems to ingest and act on MDO/MDB submissions.

No implementation deadline is stated in the document. In practice, EDL changes are coordinated between NESO and individual BSPs during scheduled testing windows. Storage operators and their aggregators should be pressing their EDL vendors for a timeline. The value of MDO/MDB depends entirely on whether NESO's dispatch algorithms actually incorporate the energy limit data — the spec enables the data flow, but operational use is a separate workstream to watch.

Source text4,640 words

Public EDL Message Interface Specification Issue 8 (CT24.13.0013) 13 April 2026 Public 2 Contents 1. Introduction ........................................................................................................................................................................... 3 1.1. Purpose and Scope ................................................................................................................................................... 3 1.2. Definitions ......................................................................................................................................................................... 4 1.3. Related Documents ................................................................................................................................................... 5 2. Message Structure Details .......................................................................................................................................... 5 2.1. Message Guidelines - General Description ............................................................................................. 5 2.2. Message Prefix Part.................................................................................................................................................... 6 2.3. Message Header Part ............................................................................................................................................... 7 2.4. Message Data Part................................................................................................................................................... 10 2.5. Control Messages ..................................................................................................................................................... 10 2.6. Instruction Messages .............................................................................................................................................. 13 2.6.2. Bid / Offer Acceptance and Deemed Instruction Message .......................................... 15 2.6.3 Reason Code Instruction Messages .............................................................................................. 16 2.6.4 Voltage / MVAR Instruction Messages ..........................................................................................17 2.6.5. Pumped Storage Instruction Messages ...................................................................................... 18 2.6.6. Instruction Message Error Codes .................................................................................................... 20 2.7. Submission Messages ............................................................................................................................................ 21 2.7.1. Submission Error codes .......................................................................................................................... 25 2.8. Undelivered Messages ......................................................................................................................................... 25 2.9. Alarm Messages ....................................................................................................................................................... 26 3. Document Status ........................................................................................................................................................... 28 Public 3 1. Introduction Any Balancing Service Provider (BSP) who participates Balancing Mechanism (BM), Replacement Reserve (RR) and Ancillary Services markets (for BMUs only) must have an EDL link to NESO. Electronic Dispatch Logging (EDL) is the mechanism by which Control Points, the operational end-points for BSPs, receive instructions from NESO and redeclare availability and dynamic parameters to NESO. 1.1. Purpose and Scope Issue 8 of this document supports changes covering Grid Code change GC0166. This change introduces two new parameters - Maximum Delivery Offer (MDO) and Maximum Delivery Bid (MDB). Public 4 1.2. Definitions Table 1: Definitions BM Balancing Mechanism BMU Balancing Mechanism Unit BOA Bid Offer Acceptance BSP Balancing Service Provider EDL Electronic Dispatch Logging – A message transfer mechanism MDO Maximum Delivery Offer MDB Maximum Delivery Bid MEL Maximum Export Limit MIL Maximum Import Limit MNZT Minimum Non-Zero Time MZT Minimum Zero Time NDZ Notice to Deviate from Zero NETA New Electricity Trading Arrangements NTB Notice to Deliver Bids NTO Notice to Deliver Offers RDR Run-down Rates RR Replacement Reserve RUR Run-up Rates SEL Stable Export Limit SIL Stable Import Limit Public 5 1.3. Related Documents • NETA – A Draft Specification for the Balancing Mechanism and Imbalance Settlement, Version 1.2, July 1999, The Office of Gas and Electricity Markets. • NETA – Data Validation, Consistency and Defaulting Rules, CT/24.12.0003. 2. Message Structure Details 2.1. Message Guidelines - General Description All messages are simple ASCII text strings to aid development of Application and Communication layers by all parties. With the exception of Server Messages the messages comprise three parts: • A message Prefix Part • A message Header Part • A message Data Part The message Prefix Part is not transmitted between computer systems. It is used for communication between the Communications Layers and the Server Layers of the system on each node. Message Prefix Parts are removed by the Server Layer from messages received from the Communication Layer before sending the messages to the Wide-area Network Layer for transmission. Messages Prefix Parts are added by the Server Layer to messages received from the Wide- area Network Layer before sending the messages to the Communication Layer. The message Header Part is constructed by the Communication Layers. The message Data Part is constructed by the Communication Layer, usually based on information from the Application Layer, although some messages are originated by the Communications Layer. This separation between Header & Data Parts is notional. In practice, some elements of the Data Part will be processed by the Communications Layers. Furthermore, the boundary between Header and Data Parts has been deliberately constructed such that the common components of all messages are arranged at the beginning of the Data Part and so may be viewed as either Header or Data Parts. Public 6 All dates and times1 are referenced to Greenwich Mean Time. Times stamps within message Data Parts are to a resolution of one minute. The format is used is dd-mmm-yyyy hh:mm. (17 characters). Note that the valid range of the time component is 00:00 to 23:59. Time stamps within message prefix parts are to a resolution of 10ms. The standard format used is dd-mmm-yyyy hh:mm:ss.nn. (23 characters). Note that the valid range of the time component is 00:00:00.00 to 23:59:59.99. Fields within the Prefix Parts and the Data Parts are delimited by a space character. All message parts are terminated with a ^ character. Fields containing variable length text items are left justified and space filled. Fields containing variable length numeric items are right justified and zero filled. The leading character of the day part of a date/time field may be a space. Messages consist of three types; control, instruction and submission. Select/deselect control messages are sent from NESO to a Control Point while path/no path control messages are sent from a Control Point to NESO. These messages control the availability of a BM Unit both to be instructed by NESO and to submit dynamic parameters. For instruction and submission messages to be exchanged, NESO must first have sent a select message while the Control Point must have sent a path message. Various message formats are defined for Ancillary Service instructions and Balancing Market Bid/Offer Acceptance instructions that are used by NESO to instruct a Control Point. Likewise, submission message formats are defined which allow a Control Point to submit various BM Unit dynamic parameters to NESO. If an error is detected by the Control Point in an instruction message, or by NESO in a submission message, the text of the message, or the truncated part thereof containing a reference number and log time will be sent back to the originator together with a pre-defined error code. 2.2. Message Prefix Part The message Prefix Part is different for each mailbox between the Communication Layer and the Server Layer. There is no Prefix Part on messages from the Communication Layer to the Server Layer on the station node, i.e. on messages in the CMS input mailbox. Table 2: Message Prefix Part for MMS Input Mailbox Field Name Start Position Field Size Description 1 Inter-machine time comparisons should only be to a minute resolution Public 7 Destination 1 6 Name of Control Point Terminator 7 1 Part terminator character "^" Table 3: Message Prefix Part for MMS Output Mailbox Field Name Start Position Field Size Description Destination 1 6 Name of Control Point Time-Stamp 8 23 Time message received from Wide-area Network. Obtained from local node system clock. Terminator 31 1 Part terminator character "^" Table 4: Message Prefix Part for CMS Output Mailbox Field Name Start Position Field Size Description Time-Stamp 1 23 Time message received from Wide-area Network. Obtained from local node system clock. Terminator 24 1 Part terminator character "^" 2.3. Message Header Part The message Header Part is a packed string of four characters followed by a terminator. The character positions and sizes of the various fields are described in Table 5 Table 5: Message Header Part Field Name Start Position Field Size Description Category 1 1 The category of message. Instruction, Submission etc. See Table 6. Public 8 Type 2 1 The type of the message. This field carries the dialogue between Communication Layers. See Table 7 for details. Instruction Type 3 1 NOTE: This field is only used for Instruction Category Messages and is a space for all other Categories of message See Table 8 for details. Error 4 1 Flag set to space by originating process. The message may be returned with the flag set. See Table 9 for details. Terminator 5 1 Part terminator character "^" Each transaction dialogue between Communication Layers consists of a single new outgoing message followed by one or more returned messages. Return messages are referenced to the original message and have return message types as shown in Table 6. They also retain the Message Category and Instruction Type of the original message. Table 6: Message Header Categories Category Description C Control Messages. See Table 10 for Data Part details I Instruction Messages. See Table 13, Table 14, Table 15, Table 16, and Table 17 for Data Part details R Submission Messages. See Table 22 for Data Part Details Table 7: Message Header Types Code Mnemonic Direction Meaning N New Send A new (real-time) message. W Waiting Return The remote Communications Layer has received & validated the referenced message. It is now waiting for manual action. Public 9 This type is often called Technical Acknowledgement in earlier papers. U User Acknowledgements Return The remote operator has seen the referenced message. A Acceptance Return The remote operator has seen the referenced message. R Reject Return The remote operator has seen the referenced message. T Telephoned Send Upon re-connection of systems, messages that have been transmitted by telephone are sent electronically to allow the systems to reconcile themselves. D Dispute Return The remote system cannot reconcile a manually entered transaction. Table 8: Message Header Instruction Types Instruction Type Code Meaning Space Control Message, Submission Message, or EDL closed instruction messages. See Table 10, Table 12, Table 13, Table 14, Table 15, Table 21 & Table 22 for Data Part details V EDL Voltage Control Instruction. See Table 16 for Data Part details. P Pumped Storage Message. See Table 17 for details Public 10 Table 9: Message Header Error Flags Error Flag Meaning Space Original message E An error is detected in a received message. Either the original message is returned to the originator with a four-character error code appended to it or a new message identifying the reference number of the original message together with a 4-character error code is sent to the originator. The error code may relate to the syntax or data consistency of the message X A message is returned to the originator. The message was valid and data consistent when first received, but while waiting for a user acknowledgement, other parameters have changed and the message is no longer consistent. It is thus flagged as eXpired i.e. a valid message that is no longer meaningful. 2.4. Message Data Part The content of the Message Data Part depends primarily on the Message Category and secondarily on the Message Type. In the case of Instruction Category Messages the Instruction Type also influences the Message Data Part. Single space characters to further enhance the readability of the messages separate fields within the Message Data Parts. The Message Data Parts for each category are defined in the following tables. 2.5. Control Messages The Message Data Part for control messages is a maximum of 56 characters. The length and contents of control messages depends on the nature of the message, the options are detailed in Table 10. Public 11 Table 10: Message Data Part for Control Messages Field Name Start Position Field Size Description Valid Type Error Flag Name 1 9 Control Point Name (VERSON message only) or BM Unit Name All Ref Number 11 10 Message Reference Number All Log Time 22 17 Time message logged by originating process All Type 40 6 Specifies the type of control message and the structure of the type dependent message part. N Type dependant Type Details Version See Table 12 Select The Control Point is selected by NGC for EDL. DESEL The Control Point is de-selected by NGC for EDL PATH There is a path from the Control Point Communication Layer to the BM Unit operator. NOPATH There is NO path from the station Communication Layer to the BM Unit operator Error Code 40, 47 or 52 4 See Table 11 for meaning Any E Public 12 Terminator 44, 39, 46, 51, or 56 1 Part terminator character "^" All Dispatch Instructions to an individual BM Unit via EDL will only take place once a PATH message from the control point, and a SELECT message from NESO have been sent. All other states will result in Instructions being issued by voice telephone. Public 13 Table 11: Control Error Messages Error Code Description C001 Invalid Control Point/BM Unit ID C002 Invalid Control Type C003 Unsupported Version Number C004 Message arrived before VERSON accept Submission and Control Messages can be issued at any time, irrespective of select and path states. Table 12: Message Data Part for Version Messages Field Name Start Position Field Size Description Type 40 6 VERSON Version 47 4 Latest Supported EDL Interface Definition. The version number is changeable and reflects the current level of messages supported at NGC and the Control Point. The current supported version is 2.1, i.e. 0021 2.6. Instruction Messages 2.6.1. Status Change Instruction Messages Public 14 Table 13: Message Data Part for Status Change Instruction Messages Field Name Start Position Field Size Description Valid Type Error Flag Name 1 9 BM Unit Name All Ref Number 11 10 Instruction Reference Number All Log Time 22 17 Time message logged by originating process All Start Instruction Code 40 5 This may be one of the following codes SYN, HTS or the numeric value 0. N, T Start Reserve 46 3 Not used. N, T Start Time 50 17 Start time of the instruction. N, T Reason Code 68 3 Three character reason code applied to steam plant; the first character explains why the instruction was issued, the second character indicates whether the BM Unit is in frequency response mode. N, T Target Instruction Code 72 5 This may be one of the following codes OFF, HTS, CHS or the numeric value 0. N, T Target Reserve 78 3 Not used. N, T Target Time 82 17 Target time of the instruction. N, T Error Code 40, 100 4 See Table 21 for meaning Any E, X Terminator 39, 44, 99 or 104 1 Part terminator character "^" All Participants and Vendors should contact NGC for an up-to-date list of reason codes and an accompanying explanation. Public 15 2.6.2. Bid / Offer Acceptance and Deemed Instruction Message A Bid Offer Acceptance will be sent to either BM Bids/Offers in the Balancing Mechanism.. The closed instruction must contain at least two MW / time value pairs up to a maximum of five value pairs that describe a closed volume of energy (in conjunction with the physical notification and any relevant previously accepted BOAs). The message Data Part for an instruction is a maximum of 183 characters in length. Table 14: Message Data Part for BOA and Deemed Closed Instruction Messages Field Name Start Position Field Size Description Valid Type Error Flag Name 1 9 BM Unit Name All Ref Number 11 10 Instruction Reference Number All Log Time 22 17 Time message logged by originating process All Type 40 4 Type of instruction. BOAI or DEEM N, T BOA Number 45 10 BM Unit Bid/Offer Acceptance Number N, T Number of Data Points 56 2 Count of the number of MW / Time pairs that make up this closed instruction. There must be a minimum of 2 pairs and a maximum of 5. N, T MW1 59 5 MW Value 1 ±nnnn N, T T1 65 17 Time Value 1 MW2 83 5 MW Value 2 Error code A N, T T2 89 17 Time Value 2 MW3 107 5 MW Value 3 Optional MW / Time pair 3; Error code B N, T T3 113 17 Time Value 3 Public 16 MW4 131 5 MW Value 4 Optional MW / Time pair 4; Error code C N, T T4 137 17 Time Value 4 MW5 155 5 MW Value 5 Optional MW / Time pair 5; Error code D N, T T3 161 17 Time Value 5 Error Code 40, 107 A, 131 B, 155 C, 179 D 4 See Table 21 for meaning Any E, X Terminator 39, 44, 106, 111, 130, 135, 154, 159, 178, 183 1 Part terminator character "^" All 2.6.3 Reason Code Instruction Messages The message Data Part for a reason code instruction message is a maximum of 71 characters. This instruction sets the current reason code for a BM Unit. It is used, for example, to instruct a BM Unit’s frequency response. Table 15: Message Data Part for Change of Reason Code Instruction Messages Field Name Start Position Field Size Description Valid Type Error Flag Name 1 9 BM Unit Name All Ref Number 11 10 Instruction Reference Number All Log Time 22 17 Time message logged by originating process All Type 40 4 Type of instruction. REAS N, T Reason Code 45 3 Three character reason code. N, T Start Time 49 17 Start time of the instruction. N, T Public 17 Error Code 40, 67 4 See Table 21 for meaning Any E, X Terminator 39, 44, 66 or 71 1 Part terminator character "^" All Participants and Vendors should contact NESO for an up-to-date list of reason codes and an accompanying explanation. 2.6.4 Voltage / MVAR Instruction Messages The message Data Part for Voltage Instruction messages is a maximum of 73 characters. All voltage control instructions are supported by EDL level 2 (VERSON 0021). Table 16: Message Data Part for Voltage / MVAR Instruction Messages (version 2.1) Field Name Start Position Field Size Description Valid Type Error Flag Name 1 9 BM Unit Name All Ref Number 11 10 Instruction Reference Number All Log Time 22 17 Time message logged by originating process All Type 40 4 Type of instruction. MVAR or VOLT N, T Value 45 4 Target value as a whole number preceded by minus ("-" = negative value), plus ("+" = positive value), or space (" " = positive value) and with 3 digits (i.e. leading zero's always supplied). Note: + zero & - zero are treated as same instruction N, T Target Time 50 17 Target time of the MVAR or VOLT instruction. N, T Error Code 40, 68 4 See Table 21 for meaning Any E, X Public 18 Terminator 39, 44, 67 or 72 1 Part terminator character "^" All 2.6.5. Pumped Storage Instruction Messages For Pumped Storage plant MW loading and pump instructions will use the closed instruction format given in Table 17. The following message format will be used to set a pumped storage unit’s: • current reason code • droop value • low frequency relay value • current operating state Voltage instruction messages will be in the standard format as described in Table 16. Table 17: Message Data Part for Pumped Storage Unit Instruction Messages Field Name Start Position Field Size Description Valid Type Error Flag Name 1 9 Pumped Storage Unit Name All Ref Number 11 10 Instruction Reference Number All Log Time 22 17 Time message logged by originating process All Reason Code 45 3 Four character reason code, (see Table 18 for more detail) N, T Start Time 49 17 Start time of the instruction. N, T Target 63 5 Depending on the reason code: a mnemonic or a real value (see Table 19 for more detail). N, T Target Time 69 17 Target time of the instruction. N, T Error Code 87 4 See Table 21 for meaning Any E, X Terminator 92 1 Part terminator character "^" All Public 19 Reason Codes can be one of the following: Table 18: Pumped Storage Reason Codes Reason Code Description LFSM Limited Frequency Sensitive Mode PSHF Carry Primary, Secondary and High Frequency Response EMRG Emergency instruction (instruction to operate outside declared parameters) FRES Fast Response Required LFRY Instruction to set a Low Frequency relay DROP Droop instruction BKDN Breakdown Public 20 Target Field can be one of the following: Table 19: Pumped Storage Targets Target Description MW Reason code to be applied to the Pumped Storage BOA Closed Instruction SH Shutdown SG Spin Gen SP Spin Pump nn.nn Set low frequency relay to nn.nn Hz. For example nn.nn could be 49.85. Where nn.nn is sent as 00.00 this should be interpreted as >remove LF relay setting=. n.n Set droop to n.n % Table 20: Pumped Storage allowable combinations MW positive output SH SG SP MW negative output nn.nn n.n LFSM X X X X X PSHF X X EMRG X X X X X FRES X LFRY X DROP X BKDN X 2.6.6. Instruction Message Error Codes The error codes in Table 21 can be used with instruction messages. Public 21 Table 21: Instruction Error Message Codes Error Code Description I001 Invalid BM Unit ID I002 Invalid Reference Number (Current reference < Last reference, or no previous reference to instruction with this number) I003 General instruction syntax error (instruction parsing failed) I004 Instruction received for a BM Unit with NO PATH I005 Instruction received before Version Control Procedure completed I006 Telephoned Instruction received with an Invalid Reference Number I007 Attempt to recover previously rejected instruction I008 Unable to log instruction I009 Invalid Telegraph Instruction Number I010 Attempt to Reject Reconciliation Instruction which has already been sent to Settlements 2.7. Submission Messages Submission messages conform to the message structure and error checking detailed in Reference 2. The structure of the Data Part depends on the parameters being re- declared, the options are detailed in Table 22. The message Data Part for Submission messages is a maximum of 107 characters. Public 22 Table 22: Message Data Part for Submission Messages Field Name Start Position Field Size Description Valid Type Error Flag Name 1 9 BM Unit Name All Ref Number 11 10 Instruction Reference Number All Log Time 22 17 Time message logged by originating process All Type 40 6 Specifies the type of Submission and the structure of the type dependent message part. N, T Type Dependent 47 Max 57 Type MEL, MIL (error code A) Table 23 RURE, RURI, RDRE, RDRI (error code B) Table 24 NDZ, NTO, NTB, MZT, MNZT (error code C) Table 25 SEL, SIL (error code D) Table 26 MDO, MDB (error code E) Table 27 Error Code 40 any, 103 (A), 79 (B), 51 (C), 57 (D), 61 (E) 4 Not used. Any E, X Terminator 39, 44, 102, 107, 78, 83, 50, 55, 56, 61, 60, 65 1 Part terminator character "^" All Public 23 Table 23: Message Data Part Variations for MEL/MIL Submission Messages Field Name Start Position Field Size Description Type 40 6 “MEL” or “MIL” keyword Time from 47 17 Start time MW from 65 9 MW at time from (±nnnnnnnn) Time to 75 17 End time MW to 93 9 MW at time to (±nnnnnnnn) Submission messages for RUR/RDR parameters contain fields that are optional. Unused fields are treated as null values. Null values are specified by filling the field with ‘*’ characters. The three valid combinations of parameters and nulls are identified in Table 24. Table 24: Message Data Part variations for RUR/RDR Export/Import Submissions Field Name Start Position Field Size Description Type 40 6 “RURE”, “RURI”, “RDRE”, or “RDRI” keywords Valid Combinations Rate 1 47 6 First Rate T T T Elbow 2 54 5 Optional Second Elbow (±nnnn) T T * Rate 2 60 6 Optional Second Rate T T ** Elbow 3 67 5 Optional Third Elbow (±nnnn) T * * Rate 3 73 6 Optional Third Rate T ** ** Public 24 Table 25: Message Data Part variations for Single Time Value Parameter Submissions Field Name Start Position Field Size Description Type 40 6 “NDZ”, “NTO”, “NTB”, “MZT” or “MNZT keyword” Time Value 47 3 Number of minutes Table 26: Message Data Part Variations for SEL/SIL Submission Messages Field Name Start Position Field Size Description Type 40 6 “SEL” or “SIL” keyword Time Value 47 9 MW level Table 27: Message Data Part for variations for MDO/MDB Messages Field Name Start Position Field Size Description Type 40 6 “MDO” or “MDB” keyword Time from 47 17 Start time MWh from 65 9 MWh at time from (±nnnn, ±nnnn.d, ±nnnn.dd or ±nnnn.ddd) Time to 75 17 End time MWh to 93 9 MWh at time to (±nnnn, ±nnnn.d, ±nnnn.dd or ±nnnn.ddd) Public 25 2.7.1. Submission Error codes A submission message is automatically acknowledged by NESO using a message with the message Header Part “RW ^”. The submission undergoes syntax and validation checking. If the submission is valid, the return message with the message Header Part “RU ^” is sent to the Control Point; otherwise, if an error is encountered, a message with the message header part “RN E” is sent with a reason code appended. Table 28: Submission Error Codes Error Code Description R001 Invalid syntax R002 Invalid BM Unit R003 Value out of bounds R004 Invalid run rate break point R005 Invalid run rate R006 Invalid combination of run rates/breakpoints R007 Invalid run rate breakpoint; breakpoints not monotonically increasing R008 FROM time does not predate TO time R009 Invalid FROM time R010 Invalid TO time R011 FROM time must be equal to or after SUBMISSION time R999 Contact NESO 2.8. Undelivered Messages There will be rare occasions when messages will not be acknowledged as successfully transferred from the Communications Layer on one node to the Communications Layer on another node. This may be due to • the message was not transferred – communications failure • the remote message server failed to acknowledge receipt of the successfully delivered message. All such messages which cannot be delivered to the remote partner are deposited in the undelivered mailbox on the sending node. Any message Prefix Part in the input mailbox is also echoed to the undelivered mailbox. Public 26 The Communications Layer must monitor this mailbox, and possibly re-present the message when connection is re-established. 2.9. Alarm Messages The Server Layer continuously monitors the Wide-area Network Layer. Whenever a connection with a remote partner changes, a message is deposited in the Alarm mailbox. Table 29: Alarm codes for CMS Alarm Mailbox Field Name Start Position Field Size Description Code 1 3 See Table 30. Time Stamp 5 23 Time alarm raised by Server Layer, obtained from local node system clock. Table 30: CMS Alarm Codes Alarm Meaning IC Input channel connected OC Output channel connected ID Input channel disconnected OD Output channel disconnected NX Network Partner Exited Public 27 Table 31: Alarm codes for the MMS Alarm Mailbox Field Name Start Position Field Size Description Destination 1 6 Name of BM Unit Code 8 6 See Table 32 Time Stamp 55 23 Time alarm raised by Server Layer, obtained from local node system clock. Table 32: MMS Alarm Codes Alarm Meaning C-P Primary Channel Connected C-S Secondary Channel Connected D-P Primary Channel Disconnected D-P(R) Primary Channel disconnected due to a link re-configuration D-S(R) Secondary Channel disconnected due to a link re-configuration D-P(U) Primary Channel disconnected due to a message being undelivered/unacknowledged D-S(U) Secondary Channel disconnected due to a message being undelivered/unacknowledged D-S Secondary Channel Disconnected NX Network Partner Exited Public 28 3. Document Status AMENDMENT RECORD Issue Draft Date Author Description of changes 8 13- Apr- 2026 BD Minor changes after GC Tech Consultation. Removed references to BOAR & RR. 8 2 19- Dec- BC GC0166 adding decimal places 8 1 26- Nov- BC GC0166 adding MDO & MDB 7 08- April- 2025 SM Replacing NGESO branding with NESO branding Modernised document formatting 6 13- Oct- Chaitali Updated NGESO branding 5 2 02- Jul- Chaitali Final Draft 5 1 25- Sep- 2018 RDG Updated to introduce new type of instruction, BOAR, for bid-offer acceptances resulting from the Replacement Reserve (RR) Market Document modernisation also undertaken 4 20- Jun- NA Add new NGC logo and quality watermark. 4 1 07- Jun- 2000 NA Updated following comments arising from EDL type testing. 3 09- May- 2000 NA Updated and issued after responding to comments on Issue 3, Draft 1. 3 1 13- Apr- 2000 RDG Updated to include Submission message reason codes 2 21- Jan- 2000 NA Issued following review. 2 1 19- Jan- 2000 NA Updated in response to comments received from OFGEM on Issue 1. Also add Start Time field to the REAS instruction and increase the size of the elbow fields in the RUR/RDR messages from 4 to 5. 1 23- Dec- 1999 NA Updated in response to comments from the NETA project team. 1 1 16 Dec 1999 NA Created from the document referred to in Reference 4.