16 Nov
2017
16 Nov
'17
3:54 p.m.
Hi list,
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.
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.
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:
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
Also in UMTS, there are overlapping UARFCNs between bands, which necessitates
a separate field for band indicator. Changes regarding these will break the
GSMTAP header structure, therefore I want to discuss about how these could be
addressed.
Best Regards,
Shinjo
--
Shinjo Park <pshinjo(a)sec.t-labs.tu-berlin.de>
Security in Telecommunications <sec.t-labs.tu-berlin.de>
TU Berlin / Telekom Innovation Laboratories
Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany
Phone: +49 30 8353 58272
23 Nov
23 Nov
6:13 p.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
2352
days inactive
2359
days old
1 comments
2 participants
participants (2)
-
Harald Welte -
Shinjo Park