The ip.access nanoBTS are small BTS with an A-bis over IP interface. RSL and OML are encapsulated in a single TCP session, whereas the TRAU frames on the actual TCH seem to be inside RTP/UDP.

This is the description of the A-bis over IP protocol as we have reverse engineered it by looking at protocol traces between a commercial BSC and a nanoBTS. We did not and do not have access to the protocol specification of ip.access.

=== Signalling Link ===

After obtaining an IP address from DHCP, the nanoBTS will attempt to make TCP connections to a IP address and port number pre-configured in the device. The standard port seems to be 3002.

Inside the TCP connection, every message is prefixed by a three-byte header: {{{
struct ipaccess_head {
u_int8_t zero;
u_int8_t len;
u_int8_t proto;
} attribute ((packed));
}}}

where the first byte is zero, the second byte indicates the length of the message payload following the header, and the third byte indicates the protocol. The following protocol values have been observed:

• 0x00 RSL messages as per GSM 08.58
• 0xfe ip.access specific messages
• 0xff OML messages as per GSM 12.21

The ip.access specific messages that we have seen are of the following message types (message type is the first byte behind the ipaccess_head): * 0x00 PING (from BTS to BSC) * 0x01 PONG (from BSC to BTS), indicates that the link is still alive * 0x04 Identity Get (from BSC to BTS) * 0x05 Identity Response (from BTS to BSC) * 0x06 Identity confirm (both ways, BTS->BSC is a request, BSC->BTS is acknowledgement)

=== TRAU link ===

Not yet reverse engineered.