Hi Shinjo,

On Thu, Nov 16, 2017 at 03:54:15PM +0100, Shinjo Park wrote:

While I was experimenting with osmo-qcdiag and other LTE stuff, I want to add NAS/EPS as a new payload type for gsmtap.h.

perfectly fine.

Unlike GSM and UMTS, LTE introduced separate layer for encryption of NAS and RRC. As a result, while NAS messages are piggybacked to LTE RRC, but after NAS security had been activated only encrypted NAS messages are available at RRC layer. This is reflected into the baseband diagnostics of various makers: Qualcomm provides separate diagnostic item for LTE NAS (both encrypted and plain) and RRC. Separate payload type for LTE RRC and LTE NAS will solve this issue. I can submit a patch if this looks positive.

Yes, please send a patch both for the gsmtap header file in libosmocore as well as for the wireshark dissector.

Also, I have a question regarding ARFCN field. Currently (in version 2) ARFCN is a 16-bit integer, with 2-bit of flags (PCS band, uplink) therefore making 14-bits available for raw value. This causes some problem in LTE:

Well, the field was really intended for GSM ARFCN, and not for UARFCN or EARFCN.

All of GSMTAP was intended for GSM, everything else was just a rather dirty addition.

1. EARFCNs for uplink are starting from 18000, which is larger than 2^14
2. There are EARFCNs even larger than 2^16 (Bands 65+, LTE-U frequencies)
3. No separate indicator for ARFCNs used by UMTS/LTE-TDD network

ACK.

Also in UMTS, there are overlapping UARFCNs between bands, which necessitates a separate field for band indicator.

ACK.

Changes regarding these will break the GSMTAP header structure, therefore I want to discuss about how these could be addressed.

Basically, we'll need a new version of the header, and then have a dissector for both the old and the new format. UMTS/LTE applications that care about U/EARFCN can then make use of the new header version while existing legacy programs continue to use the old format.

The new common header should be much shorter. It shouldn't even contain fields like timeslot / subslot that don't make sense on non-TDMA systems. Even ARFCN could be removed and, and then be part of a type-specific 'next header' or 'option header'.

so something like

struct gsmtap_v3_header { uint8_t version; uint8_t hdr_len; uint8_t type; uint8_t antenna_nr;

int8_t signal_dbm; int8_t snr_db; uint8_t sub_type; uint8_t res; /* or maybe expand sub_type to 16bits? */ };

followed by

struct gsmtap_opt_hdr_gsm { uint16_t arfcn; uint8_t timeslot; uint8_t sub_slot; };

struct gsmtap_opt_hdr_umts { uint32_t uarfcn; uint8_t band; ... };

struct gsmtap_opt_hdr_lte { uint32_t earfcn; ... };

seems like a good idea to me.