RFC: new type for NAS/EPS in gsmtap.h and question

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Thu Nov 23 17:13:05 UTC 2017


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.
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list