EncapsulationPage » History » Version 3

matt, 10/24/2017 11:45 PM

1 2 matt
h1. P25-in-UDP Encapsulation
2 1 zecke
3 1 zecke
The P25-in-UDP encapsulation is known as P25CAI. THIS allows frames conforming to the P25 common air interface (CAI) to be passed inside UDP datagrams.  This allows for BOTH unicast and multicast distribution of P25 CAI message traffic across IP networks. Sending P25 CAI traffic across an IP network may be used to link repeaters via the Internet and allow for traffic analysis and logging services to be implemented using conventional computing equipment.
4 1 zecke
5 1 zecke
Every UDP frame contains an encapsulation header and an encapsulated P25 frame:
6 3 matt
7 1 zecke
 * The encapsulation header provides meta-information for the P25 frame.
8 1 zecke
 * The encapsulated P25 CAI frame is the message as it is sent over the air interface.
9 1 zecke
10 2 matt
h2. The P25CAI Encapsulation Header
11 2 matt
12 1 zecke
The UDP datagram begins with a short header which is used to describe the P25 CAI frame. The format of the encapsulation header is closely modeled on the [ radiotap] header which is widely used to describe IEEE 802.11 traffic; and also on the [ gsmtap] header which is used by Airprobe to describe GSM traffic. The minimum information contained by this header is described as follows:
13 1 zecke
14 2 matt
15 1 zecke
struct p25cai_hdr {
16 1 zecke
  uint8_t version;  /* 0 at present. */
17 1 zecke
  uint8_t pad;
18 1 zecke
  uint16_t length;  /* length of the header */
19 1 zecke
  uint32_t seq_no;  /* frame sequence number */
20 1 zecke
  uint32_t present; /* bit-mask indicating which optional fields are present */
21 1 zecke
} __attribute__((packed))
22 2 matt
23 1 zecke
24 1 zecke
The header contains both mandatory and optional fields and numbers are all in network byte order. The optional fields are, if present, specified by setting the appropriate bit in the "present" bitmask. These fields are listed in order of bit number:
25 1 zecke
26 1 zecke
|| Bit number || Field ||
27 1 zecke
||     0      || [wiki:P25CAITimestamp  Timestamp (in ms)]      ||
28 1 zecke
||     1      || [wiki:P25CAIFrequency  Frequency (in kHz)]     ||
29 1 zecke
||     2      || [wiki:P25CAIChannel    Logical channel]        ||
30 1 zecke
||     3      || [wiki:P25CAIPower      RSSI/TX power (in dBm)] ||
31 1 zecke
||    31      || [wiki:P25CAIExtended   Extended bitmask]       ||
32 1 zecke
33 1 zecke
When an optional field is indicated to be present by the present bitmask then the following rules apply:
34 1 zecke
 * Fields are strictly ordered; The developer can specify any combination of optional fields, but the data must appear following the encapsulation header in the order they are specified in the present bitmask (or more accurately, in the order the bit numbers for the present bitmask are defined).
35 1 zecke
 * Field lengths are implicit: the encapsulation header format does not specify field lengths, it is expected that the developer knows the corresponding length based on the data field name.
36 1 zecke
 * Variable-length fields are not supported since field lengths are implicit.
37 1 zecke
 * Support for extended bitmasks must be implemented, see below.
38 1 zecke
39 2 matt
h3. Field Order
40 2 matt
41 1 zecke
All fields are required to use network byte-order. This applies to optional fields and also to mandatory fields including the version, length, channel and present fields in the encapsulation header. This is in contrast to gsmtap and Radiotap but unlike those headers the P25CAI encapsulation is intended for transmission over the network.
42 1 zecke
43 2 matt
h3. Field Alignment
44 2 matt
45 1 zecke
The encapsulation requires that all fields (whether mandatory or optional) be naturally aligned. All fields in the encapsulation header must be aligned to natural boundaries. That means all 8-, 16-, 32-, and 64-bit fields must begin on 8-, 16-, 32-, and 64-bit boundaries, respectively. In this way, generators and parsers can avoid unaligned accesses to encapsulation header fields. This wiki has adopted the stdint.h convention of using uint64_t, uint32_t and uint16_t to denote 64-, 32- and 16-bit quantities.
46 1 zecke
47 2 matt
h3. Extended Bitmasks
48 2 matt
49 1 zecke
To allow for future extension parsers extented bitmasks will be used. If bit 31 of the present field is set, an extended present bitmask is present. Radiotap parsers must check for the presence of bit 31 in the present field to identify if a second 32-bit bitmask is present in the encapsulation header. Additional bitmasks may be chained to the end of extended bitmasks by setting bit 31 in each bitmask to indicate a follow-up one. Field bits in an extended bitmask still counted starting from 32, 64, etc. so that field number 63 is also reserved because bit 31 is reserved in every (extended) bitmask. 
50 1 zecke
51 2 matt
h3. Code
52 2 matt
53 1 zecke
The p25lib library provides support for manipulating the encapsulation header and P25 CAI frames. A simple stand-alone parser and formatter in C/C++ is provided as well as code for handling CAI data units. We are re-factoring the OP25 codebase so that GNURadio is used for the signal processing and p25lib for all higher-level frame handling. Until the official release of p25lib we'll give the formatter/parser as attachments to this page.
54 1 zecke
55 2 matt
h3. The Encapsulated P25CAI Frame
56 2 matt
57 1 zecke
The encapsulated P25 frame immediately follows the encapsulation header. The format of the frame is given by the P25 Common Air Interface standard which specifies the message types, their content and bit ordering.
58 1 zecke
59 1 zecke
Project 25 FDMA Common Air Interface Description (TIA-102.BAAA-A),
60 1 zecke
Telecommunications Industry Association,
61 1 zecke
2500 Wilson Boulevard, Arlington, VA 22201, USA,
62 1 zecke
September 2003
Add picture from clipboard (Maximum size: 48.8 MB)