EncapsulationPage » History » Version 1

zecke, 04/22/2017 04:22 PM

1 1 zecke
== 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 1 zecke
 * The encapsulation header provides meta-information for the P25 frame.
7 1 zecke
 * The encapsulated P25 CAI frame is the message as it is sent over the air interface.
8 1 zecke
9 1 zecke
=== The P25CAI Encapsulation Header ===
10 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:
11 1 zecke
12 1 zecke
13 1 zecke
struct p25cai_hdr {
14 1 zecke
  uint8_t version;  /* 0 at present. */
15 1 zecke
  uint8_t pad;
16 1 zecke
  uint16_t length;  /* length of the header */
17 1 zecke
  uint32_t seq_no;  /* frame sequence number */
18 1 zecke
  uint32_t present; /* bit-mask indicating which optional fields are present */
19 1 zecke
} __attribute__((packed))
20 1 zecke
21 1 zecke
22 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:
23 1 zecke
24 1 zecke
|| Bit number || Field ||
25 1 zecke
||     0      || [wiki:P25CAITimestamp  Timestamp (in ms)]      ||
26 1 zecke
||     1      || [wiki:P25CAIFrequency  Frequency (in kHz)]     ||
27 1 zecke
||     2      || [wiki:P25CAIChannel    Logical channel]        ||
28 1 zecke
||     3      || [wiki:P25CAIPower      RSSI/TX power (in dBm)] ||
29 1 zecke
||    31      || [wiki:P25CAIExtended   Extended bitmask]       ||
30 1 zecke
31 1 zecke
When an optional field is indicated to be present by the present bitmask then the following rules apply:
32 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).
33 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.
34 1 zecke
 * Variable-length fields are not supported since field lengths are implicit.
35 1 zecke
 * Support for extended bitmasks must be implemented, see below.
36 1 zecke
37 1 zecke
==== Field Order ====
38 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.
39 1 zecke
40 1 zecke
==== Field Alignment ====
41 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.
42 1 zecke
43 1 zecke
==== Extended Bitmasks ====
44 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. 
45 1 zecke
46 1 zecke
==== Code ====
47 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.
48 1 zecke
49 1 zecke
=== The Encapsulated P25CAI Frame ===
50 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.
51 1 zecke
52 1 zecke
Project 25 FDMA Common Air Interface Description (TIA-102.BAAA-A),
53 1 zecke
Telecommunications Industry Association,
54 1 zecke
2500 Wilson Boulevard, Arlington, VA 22201, USA,
55 1 zecke
September 2003
Add picture from clipboard (Maximum size: 48.8 MB)