RMIP Overview
The Radio Modem Interface Protocol (RMIP) is an l block mode protocol used for signalling mobile data messages (status messages and data messages) and supervisory information (acknowlegements, etc.) between a radio-modem and a mobile data terminal or an MDS700 gateway and host computer system. RMIP can be transported over RS232 or TCP/IP Ethernet.
The RMIP protocol was devised by Thorcom Systems as the main transmission protocolin its FFSK and GMSK based modems and wide-area systems used on conventional data channels for point-to-point communications and over wide area multi-basestation systems too..
The RMIP protocol provides a method for supplying infomation about the type of message or transaction being performed as well as the indended destination address and optional message identification, time stamps and the user data itself.
RMIP provides the ability to
Important points of note about RMIP are:
 |
RMIP is the user presentation of messages transmitted by the air interface protocol - the air interface protocol is significantly different and more complex than RMIP and is outside the scope of this document. |
| |
|
|
The modem (or Gateway) takes responsibility for the transmission, re-transmission attempts, number of transmission attempts, etc. on the radio channel and presents messages after the re-transmission attempts, if necessary, have been made. |
| |
|
|
The radio system is "message orientated" or "transaction orientated" in nature. Messages (status, data, extended status, etc.) are "handed off" to the modem and the modem gives back a success/fail response. This is in contrast to systems which are "connection orientated" or "stream orientated" in nature. |
RMIP over RS232 Serial Interfaces
The modem (mobile terminated) RMIP user interface is based on the use of an RS232, asynchronous, serial data link with a DLE-STX/DLE-ETX form of packet framing to send all messages between the computer equipment and the modem.
All messages are in the generic form:
-----------------------------------------------------------------------------------------------
| SYN | DLE | STX | OPCODE | (ADDR) | (MSGID) ! (DATA BYTES ...) | DLE | ETX | (CHK) |
-----------------------------------------------------------------------------------------------
Note: items above shown in brackets () are optional depending on the message context.
Transmission is asynchronous RS232 with 8 data bits, 1 start bit, 1 stop bit and no parity and based on the use of 8-bit bytes or "octets".
The various fields are:
SYN (16hex). The ASCII synchronisation character and is sent at the start of a frame to flush any line noise or RS232 error condition from the UART's receive shift register and is considered as a pre-amble character and not part of the frame. The SYN character is always sent by the modem at the start of a frame. The SYN character is not required by the modem on receive but may be sent before the start of frame. The use of the SYN character is recommended but not a requirement.
DLE (10hex) and STX (02hex) The unique sequence which identifies the start of frame
OPCODE an 8-bit binary number which indicates the type of message to/from the modem (the operation code).
ADDR a 16-bit number (two bytes) which represents the "to" or "from" address of the unit involved in the message. The address is "little endian", ie. transmitted low-byte first high-byte second.
MSGID a 16-bit number (two bytes) which represents the users reference number for the message, ie. a unique message identity. The message identity number is used by the modem to track duplicates and is returned in acknowledgement messages at the end of a delivery attempt.
DATA the optional, variable length, user data which is being transferred and may be a status byte, extended status data or variable length message data.
DLE (10hex) the unique end of frame sequence
ETX (03hex)
CHK an optional message checksum, ie. a block check sequence for the message which is only output or checked if RMIP checksums are enabled.
RS232 serial parameters
RMIP devices using RS232 serial ports use parameters which work independently of the radio channel. They are defined so that binary data can be transferred easily and set to a fixed speed which is significantly faster than the radio signalling rate. This ensures that the latency on the RS232 link is minimal compared with the radio channel. The RS232 port parameters for the user interface are as follows:
- Speed: 9600 bps
- Data bits: 8
- Start bits: 1
- Stop bits: 1
- Parity: None
- Flow control: CTS/RTS (hardware flow control)
Hardware flow control is used in both directions to prevent loss of data should buffers become full. In normal operation where only one message is in transit between the modem and user equipment at any time the flow control is not required.
Message transparency
Message transparency is achieved using "DLE stuffing". This technique allows ASCII (plain text) or raw Binary to be transferred across the serial link in an order fashion.
The DLE character normally only ever appears in the start or end sequence on a frame. In order to represent a DLE character inside a data frame a DLE followed by a second DLE is sent. The receiving party recognises the double DLE sequence as meaning a single DLE was intended inside the frame.
Checksum handling & calculation
The RMIP protocol permits the use of frame checksumming with an optional single byte checksum at the end of the frame.
The block checksum takes the form of an 8-bit (byte) value (range 0-255, ie. all values are valid) which is transmitted after the end of closing DLE-ETX at the end of the frame. The checksum is calculated by starting with the initial value of FFhex and exclusive OR-ing all user data byte values in the buffer. The calculation excludes the DLE-STX and DLE-ETX sequences and excludes the additional characters added during transparency (DLE stuffing). Thorcom can supply C language source code for low-level RMIP message transmission and reception and includes the block checksum algorithm.
Delivery of RMIP messages and retries
RMIP and operation of the modem is predicated on the following rules and assumptions:
|
The RS232 link between mobile and modem, or between host and gateway computer is highly reliable, short and virtually error free(whereas the RF/radio channel is not) |
|
Messages to the modem (or to the Gateway) always result in an outcome (acknowledgment or reject with an optional intermediate ack before them - if enabled)
|
|
Messages received by the modem (or Gateway/Router infrastructure) from the radio channel are delivered to the user equipment (terminal, computer etc.) in an unsolicited fashion |
|
The user equipment must always be ready to accept inbound, unsolicited, RMIP messages - these messages may occur at any time, and transactions may overlap, for example:
Host -> Gateway Send Extended Status=123; To=1016; MsgId=10
Gateway -> Host Intermediate Ack; Msgid=10, To=1016
Gateway -> Host Received Extended Status=67; From=94; Msgid=71
Gateway -> Host Ack; Msgid=10, To=1016
|
|
There is no "retry" mechanism on the RMIP interface. The optional checksum (software configurable) can be used to indicate a failed message delivery. It should, however, be considered a system failure if the checksum is ever found to be incorrect and require manual intervention to rectify whatever fault is causing the unreliable data transmission. Since real-time data can be arriving at the gateway/host from several sources in quick succession it is not practical, or sensible, to attempt re-delivery across the RS232 link.
Furthermore, it is a requirement of the radio channel access rules that acknowledgements are "turned around" in under 100mS and this does not permit time for re-tries on the RS232 serial link.
|
|
It is most important to realise and understand that the RMIP output from a mobile modem or host port on a Gateway is:
Operated in an unsolicited fashion (messages arrive when they want to without prior warning).
|
|
Able to deliver messages in an interleaved form, for example you can pass a data message to a modem, receive an intermediate acknowledgement to indicate start of a transaction, then receive a network time protocol broadcast or data from another mobile before receiving the final outcome (Ack/Nak) for the transaction which you started.
|
|
On a mobile modem only one data transaction or status transaction may be pending at any time - further RMIP input is received but not processed until the outcome of the pending transaction is known, ie. an Ack or Nak has been generated.
|
|
On a host port of the Gateway multiple, and unlimited, transactions may be started by the host in an overlapping and interleaved form. |
Further Recommendations
Thorcom strongly recommends the implementation of the RMIP handling, especially on receive, to be based on the use of a software "finite state machine" in order that all RMIP message types are handled at the appropriate time with the appropriate action(s) being taken. Thorcom can supply example source code in C-language which receives and processes RMIP messages.
Messages between modem and computer equipment
RMIP messages are transferred between the modem and the computer equipment and there are generally two types of message: those which result in data transfer across the radio channel and those which query or alter settings in the modem locally without a radio transmission. Each message has an operation code, followed by optional data. The modem inspects RMIP messages on arrival and validates them. Messages which are not correct (for example with an incorrect address or incorrect data length) are 'rejected' by the modem, ie. the modem returns a message to the attached device with a "reject message" and "reason code".
Message sequence numbers
In any wide area packet switched radio system it is important to have message sequence numbers to allow the delivery of messages to be handled in a controlled manner. In particular one mobile may receive several copies of a message for it from another unit if the acknowledgement (travelling the opposite direction) is missed. The same is true for larger infrastructure based systems where several different hilltops may transmit the same message to a mobile - this could cause unwanted duplicate messages on the RMIP interface if message sequence numbers are not used. The modem (and Gateway) implement a technique for removal of duplicate messages using a combination of a user provided message sequence number and the sender's call sign. Each message (status or data) when submitted for transmission is submitted with a 16-bit, sequential, unique and non-zero message sequence number (referred to as MSG ID). This number is transmitted along with the other fields of the data and is used by the receiving modem (and network infrastructure) to detect and remove duplicates. The modem (or Gateway, in the case of host connections) keeps track of the message number in use for the current out-bound transaction and returns it in the acknowledgement frame so that the application can determine which message/transaction the acknowledgement belongs to. Message sequence number zero (0) is a special case and is used with standard ETSI status (1-16) messages which do not have their own sequence numbers.
Registration, Network time and message time-stamps
The following facilities, described in this section, apply only to larger infrastructure based systems as they are controlled by the central Gateway/Router computer.
Registration
When a mobile first becomes active (power is applied) it attempts "registration" on the network. The mobile transmits a registration request and expects a registration acknowledgement reply. On receipt of a successful reply the mobile sets its internal clock to network time and enters the "in service" state and puts the "CON" (Connected) LED on. The mobile modem reflects the CON light as RS232 pin 8 (Data Carrier Detect). The Mobile Data Terminal (MDT) may sense the state of pin-8 (DCD) to determine whether the mobile modem/radio are "in service" of the network. Registration has to be enabled using MLPP and only has a meaning on infrastructure based networks. Enabling registration on "single base" or "mobile only" systems will cause the unit to be unable to send any data as it will fail to register.
Network time protocol broadcasts
The Gateway/Router transmits periodic "network time protocol" broadcast messages which are receivable by all mobiles. Mobiles receive and process network time protocol updates and set their internal clocks to "clock time" from these broadcasts. Network time broadcasts permits all mobiles on the radio system to have the same concept of time whether they are equipped with a GPS receiver or not. On receipt of a network time protocol broadcast the mobile updates its clock and outputs an RMIP NTP packet (Opcode 08hex) to indicate the current time to the attached Mobile Data Terminal.
Message time-stamps
The Gateway computer and Mobile modem use message time-stamps internally when signalling with Extended Data, Extended Status and Extended Acknowledgement. These time-stamps are also in ANSI "time_t" format and are used internally be the Gateway for journalling the mobile data into and out of the Gateway computer. The time-stamps on Extended Status, Extended Data and Extended Acknowledgement are not presented through the RMIP interface.
|