École Centrale de Nantes - Université de Nantes - École des Mines de Nantes

MASTER AUTOMATIQUE ROBOTIQUE ET INFORMATIQUE APPLIQUÉE

SPECIALITY : TRCS
Year 2016 / 2017

Thesis Report

Presented by:
SALLOUM Hassan
25/08/2017
At Ecole Central Nantes

TITLE
Decoding radio messages of the layer3 protocols
In GSM, UMTS and LTE Networks

JURY

Referring teacher: MOLINARO Pierre

Thesis tutor: DUCLOS Laurent

Laboratory: LS2N
2
Acknowledgements
This master internship is the most challengeable and honorable achievement during my study as master
student in real time embedded system. This work could not have been done without the patient of my
supervisor “Mr. Laurent Duclos” and the support and encouragement of his team, whom provided me
with valuable help in fixing problems and granted me access to specific tools.

Also i would like to express my sincere thanks to my responsible in the ECN University Dr. Pierre
Molinaro and our master responsible Pr. Olivier Roux and all the administration team.

Besides, thanks to my friends who have always been encouraging and cheering me up.

3
Table of contents
ACKNOWLEDGEMENTS ................................................................................................................................................. 3
TABLE OF CONTENTS .................................................................................................................................................... 4
LIST OF FIGURES ........................................................................................................................................................... 6
LIST OF TABLES ............................................................................................................................................................. 7
CHAPTER 1. GENERAL INTRODUCTION ......................................................................................................................... 8
1.1. OBJECTIVE OF THESIS ....................................................................................................................................................... 8
1.2. ORANGE TELECOM.......................................................................................................................................................... 8
1.3. MOBILE FUNCTIONALITY................................................................................................................................................... 8
1.4. MOBILE ACCESS TECHNOLOGY ........................................................................................................................................... 9
1.5. OSI MODEL ................................................................................................................................................................. 10
CHAPTER 2. MS - LAYER 3 PROTOCOLS ........................................................................................................................12
2.1. GSM LAYER 3 PROTOCOLS ............................................................................................................................................. 12
2.1.1. Connection management – CC and SMS .......................................................................................................... 13
2.1.2. GSM layer 3 message format ........................................................................................................................... 14
2.2. UMTS AND LTE LAYER 3 PROTOCOLS............................................................................................................................... 15
2.2.1. Channelization.................................................................................................................................................. 16
2.2.2. Access stratum protocol (AS)............................................................................................................................ 17
2.2.2.1. RRC establishment ....................................................................................................................................................... 17
2.2.2.2. IE of RRC connection request ....................................................................................................................................... 18
2.2.3. Non access stratum protocol (NAS) .................................................................................................................. 19
2.2.3.1. UE- NAS UMTS .............................................................................................................................................................. 20

CHAPTER 3. EXISTING DECODER ..................................................................................................................................22

3.1. ONLINE WEB DECODING ................................................................................................................................................. 22
3.2. WIRESHARK ................................................................................................................................................................. 23
3.2.1. Sniffing GSM traffic with gr-gsm method using RTL-SDR ................................................................................. 24
3.2.2. 3GPP decoder ................................................................................................................................................... 27
3.3. XCAL DECODER............................................................................................................................................................ 28
CHAPTER 4. ENCODING METHODOLOGY .....................................................................................................................30
4.1. PROTOCOL DEFINITION .................................................................................................................................................. 30
4.2. ABSTRACT SYNTAX NOTATION (ASN.1) ............................................................................................................................. 31
4.2.1. ASN.1 encoding rule ......................................................................................................................................... 31
4.2.2. ASN.1 module case study ................................................................................................................................. 32
4.3. CSN.1 ....................................................................................................................................................................... 33
4.4. ENCODING METHODOLOGY OF CC AND MM PROTOCOL ...................................................................................................... 34
4.5. ASN.1 COMPILER ......................................................................................................................................................... 36
4.5.1. ASN.1 free open source compiler ..................................................................................................................... 36
4.5.1.1. Quick start with ASN.1 compiler .................................................................................................................................. 37

CHAPTER 5. NETPROTOOL DECODER ...........................................................................................................................40

5.1. GUI APPLICATION ......................................................................................................................................................... 40
5.2. NETPROTOOL – SCENARIO 1 ........................................................................................................................................... 42
5.2.1. Diag-Parser method ......................................................................................................................................... 43
5.2.1.1. Configuring the 3G/LTE shield ...................................................................................................................................... 45
5.2.1.3. diag-parser setup ......................................................................................................................................................... 47
5.2.1.4. Result............................................................................................................................................................................ 47

4
 5.2.2. Xgoldmon method ............................................................................................................................................ 48
5.2.2.1. Xgoldmon setup ........................................................................................................................................................... 48
5.2.2.2. Result............................................................................................................................................................................ 48
5.3. NETPROTOOL– SCENARIO 2 ............................................................................................................................................ 49
5.3.1 AirPrime MC Series Development Kit ................................................................................................................ 49
5.3.2. Linux QMI SDK application ............................................................................................................................... 50
5.3.2.1. QMI SDK architecture ................................................................................................................................................... 51
5.3.2.2. Configuration setup ...................................................................................................................................................... 52
5.3.2.3. Functionality ................................................................................................................................................................. 53
5.3.3. Result................................................................................................................................................................ 55
5.4. NETPROTOOL– SCENARIO 3 ............................................................................................................................................ 56
5.4.1. Universal serial bus (USB)................................................................................................................................. 56
5.4.1.1. USB Types of data transfers ......................................................................................................................................... 57
5.4.1.2. How is data sent across the USB? ................................................................................................................................ 57
5.4.2. Result................................................................................................................................................................ 58
CONCLUSION ...............................................................................................................................................................59
LIST OF ABBREVIATION ................................................................................................................................................60
REFERENCES ................................................................................................................................................................62
ANNEXES .....................................................................................................................................................................65

5
List of figures
Figure 1: Cellular network generation ................................................................................................................. 9
Figure 2: OSI module architecture..................................................................................................................... 10
Figure 3: User equipement layer3 protocols ..................................................................................................... 11
Figure 4: GSM network layers architecture ...................................................................................................... 12
Figure 5: Call control scenario over GSM .......................................................................................................... 13
Figure 6: Short message service scenario over GSM ......................................................................................... 13
Figure 7: GSM layer 3 message structure ......................................................................................................... 14
Figure 8: UE – UMTS layer 3 protocol architecture ........................................................................................... 15
Figure 9: UE – LTE layer 3 protocol architecture ............................................................................................... 15
Figure 10: RRC connection establishment ......................................................................................................... 18
Figure 11: LTE signalling messages .................................................................................................................... 19
Figure 12: Short message service scenario over UMTS ..................................................................................... 21
Figure 13: GPRS mobility management scenario over UMTS ........................................................................... 21
Figure 14: XML decoded data for RRC-DL-DCCH using 3GPP UMTS ASN.1 decoder from Marben .................. 22
Figure 15: Canonical HEX dump for RRC connection request extracted by XCAL ............................................. 23
Figure 16: Capturing result for LTE-RRC.CCH using Wireshark.......................................................................... 24
Figure 17: grgsm_livemon tools for calibrating the frequency of the RTL-SDR ................................................ 26
Figure 18: Wireshark use RTL-SDR and gsmtap filter for detecting radio messages ........................................ 26
Figure 19: Decoding test for UMTS NAS messages ........................................................................................... 27
Figure 20: This screenshot show us the LTE signaling messages extracted by XCAL ........................................ 28
Figure 21: ASN.1 module named FooProtocol .................................................................................................. 32
Figure 22: ASN.1 message based on the FooProtocol ....................................................................................... 32
Figure 23: Two Examples of ASN.1 module ....................................................................................................... 33
Figure 24: requirement for UMTS layer3 ciruit switch ...................................................................................... 34
Figure 25: ECN and ASN.1 modules for message headers ............................................................................... 35
Figure 26: Existing decodder in ASN.1 open source compiler........................................................................... 38
Figure 27: Netprotool application ..................................................................................................................... 40
Figure 28: Python code of the Netprotool application ..................................................................................... 41
Figure 29: Raspberry PI interfaces..................................................................................................................... 42
Figure 30: Raspberry PI conncet LTE shield ....................................................................................................... 44
Figure 31: LTE shield interface connectevity with the Raspberry PI ................................................................. 44
Figure 32: Script for connecting to the network ............................................................................................... 46
Figure 33: Script for disconnect from the network ........................................................................................... 46
Figure 34: Script for establishement the ppp connection ................................................................................. 47
Figure 35: Development Kit for MC Sierra module ........................................................................................... 49
Figure 36: Interface architecture of the AirPrime MC Series Development Kit [29] ......................................... 49
Figure 37: QMI SDK architecture ....................................................................................................................... 52
Figure 38: Run packing demo sample app......................................................................................................... 54
Figure 39: Application to retrieve the module ID .............................................................................................. 54

6
List of tables
Table 1: RRC connection request structure ....................................................................................................... 18
Table 2: Decoding possibility of the 3GPP decoder........................................................................................... 27
Table 3: Quectel EC25-X specifications ............................................................................................................. 43
Table 4: AT command use ................................................................................................................................. 51
Table 5: Description for some AT command ..................................................................................................... 51
Table 6: How it can be the comparison between the two test ......................................................................... 58

7
 Chapter 1. General introduction

1.1. Objective of thesis

Due to the nature of wireless communications, transmission and reception of data can never be
guaranteed. Data may be delayed, corrupted (i.e., have errors) or be totally lost. For that, the research
areas of the orange laboratories focusing on the automated testing systems to check the network
performance. One of this research idea is the radio trace for mobile technology.

The main idea of my internship, was to develop an application based on raspberry PI microprocessor
to decode some of captured radio messages sent and received by mobile phone, focusing only on the
layer 3 in radio protocol architecture of GSM, UMTS, and LTE radio network interface.

1.2. Orange Telecom

ORANGE is a French Multinational Telecommunication Company. It was formerly known as France
Telecoms S.A. It was founded in 1988. The head office of Orange is located in the 15th
Arrondissement of Paris [1].

- It has 105,000 employees in France and 170,000 elsewhere. It has 263 million customers.
- I has geared up its revenue to 43.5 billion euros according to 2012.
- The company is a component of the Euro Stoxx 50 stock market index.
- The Orange is all for its brand for internet, mobile, landline and IPTV series.

Orange is the sole brand in terms of landline and internet. It took over the business of internet and
landline of France Telecom and Wanadoo in the year 2006. Orange has 13.7 million broadband ADSL
customers worldwide and out of which 67% are in France.

1.3. Mobile functionality

A mobile phone is an electronic device used for mobile telecommunications over a cellular network
of specialized base stations known as cell sites.

Cell phone is basically intended for Voice communication. In addition to the standard voice function,
new generation cell phones bolster numerous extra services, and features, for example, SMS for
content informing, email, bundle changing for access to the Internet, gaming, Bluetooth, camera with
video recorder and MMS for sending and getting photographs and video, MP3 player, radio and GPS.

8
The cellular system is the division of a region into small cells. This permits broad recurrence reuse
over that region, with the goal that many individuals can utilize the cell phones simultaneously. The
cellular system has various favorable circumstances like expanded limit, diminished power usage,
larger coverage bigger scope zone, lessened obstruction from different signs and etc.

1.4. Mobile access technology

Figure 1: Cellular network generation

The 2G has marked the transition from analog to digital for mobile telephony, based on the GSM
(Global System for Mobile Communication) standard is a digital mobile telephony system [2]. .

GSM is a circuit-switched network, ideal for the delivery of voice but with limitations to transfer low-
volume digital data (mainly text, with SMS or photos, with MMS). GSM is characterized by the
possibility of a speech exchange for a theoretical maximum rate of 9.6 Kbit / s.

However, the standard for GSM was designed to evolve and in 2000 the introduction of General Packet
Radio Service (GPRS) added packet-switched functionality, kick-starting the delivery of the internet
on mobile handsets. GPRS typically reach downlink speeds of up to 171Kbps.

The next advance in GSM radio access technology was EDGE (Enhanced Data rates for Global
Evolution), or Enhanced GRPS. Provides theoretical maximum speeds of 384 Kbit / s and practices of
about 150 Kbit / s.

The 3G is the third generation of mobile telephony, it includes the Universal Mobile
Telecommunications System (UMTS) technologies. These technologies allow speeds much faster than
those of the previous generation, and allow multimedia uses such as video transmission, mobile TV,
video telephony or broadband internet access.

9
UMTS is characterized by theoretical bit rates of the order of 2 Mbit /s. In a few years, extensions have
been developed to improve the proposed flows:

The HSPA (High Speed Packet Access), referred to as the 3.5G generation, is characterized by a
UMTS evolution for a theoretical maximum rate of 14.4 Mbit / s and practical about 3.6 Mbit / s).

The HSPA + (High Speed Packet Access +), referred to as the 3.7G generation, is characterized by a
theoretical maximum throughput of 21Mbit / s and a practical speed of about 5Mbit / s.

The 4G is the fourth generation of mobile telephony. It is marked by the arrival of the new LTE
technology (Long Term Evolution), which is characterized by a theoretical rate of 150 Mbit / s. An
extension of the 4G, the LTE-Advanced (Long Term Evolution Advanced). The main developments
4G are the increase in theoretical maximum speeds. The user thus has a connection approximately 3
times faster than in 3G.

1.5. OSI model

The OSI Model was created based on recommendations from the International Organization for
Standardization (ISO) in 1980. The OSI model depicts how data communications should take place. It
splits the functions or processes into seven groups that are described as layers [3].

Telecommunication networks are modeled by a graded order of hierarchical layers to make

standardization and conception easier. The role of each layer is to provide services to the layer above,
relying on those offered by the layer below. The higher the layer, the more services it can offer (but
the more abstract their definitions are!) and the less important the way data are conveyed becomes.

Figure 2: OSI module architecture

10
Without making this introduction too big by describing each layers separately i would like to explain
a little more about Network Layer which is also known as Layer 3 in mobile networking as my 6
months of internship at Orange was mostly based on layer3.

- Basically, in this layer it establishes the paths which are used to transfer the data packets between
the devices on network.

- It provides transferring of variable length data sequences from source to destination host via one
or more networks, maintaining the quality of service functions.

- Connection model: Connectionless communication. Such as IP, Host addressing and Message
forwarding are the other functions of this layer.

- Some of the protocols are: IPv4/IPv6, IPsec, IPX, ICPM, IGPM, RIP and RSMLT.

Figure 3: User equipement layer3 protocols

- UE UMTS - CS - Control plane: NAS stack functions it consists of CM and MM layers

- UE UMTS - CS - User plane: NAS stack functions do not include CM and MM layers but it
includes application data layer protocol end to end.

- UE UMTS - PS - Control plane: NAS stack functions it consists of SM and GMM layers.

- UE UMTS - PS - User plane: AS part incorporates PDCP (Packet Data Convergence).

- UE UMTS - PS - User plane: NAS part incorporates packet protocol data (IP/PPP/..) and packet
data applications (FTP/HTTP/..).

11
 Chapter 2. MS - layer 3 protocols

The 2G part of our application includes only the decoding option for some radio signals in call control
and short message service sublayers of the connection management (CM) protocol.

And for the UMTS, LTE part includes only the decoding option for some radio signals in radio
resource control (RRC) sublayer of the Non access stratum protocol.

2.1. GSM layer 3 protocols

Figure 4: GSM network layers architecture

At layer-3 in GSM-MS there are three protocols involved as mentioned below with their respective
functions [4]:
- RRM- Stands for Radio Resource Management: takes care of radio channel and handover
functionalities. Assign, maintain and release radio frequency carriers/channels.

- MM- Stands for Mobility management: takes care of location update, registration, and security
and authentication functionalities of mobile station with the GSM network.

- The CM- stands for connection management is responsible for: Call Control (CC),
Supplementary Service Management (SS), and Short Message Service Management (SMS).

The GSM depends on different channels in which the data is carried. Also, these channels are divided
into two types, physical channels and logical channels. The Physical channels are determined by the
timeslot, whereas the logical channels are determined by the information carried within the physical
channel.
12
2.1.1. Connection management – CC and SMS
The Call Control (CC) designed for: making and receiving phone calls. CC manages everything
related to phone calls, from call establishment to call tear down and everything in between. It allows
the user to make, accept and hold calls [5].

And the Short Message Service (SMS) used to exchange text messages, pictures, sounds and many
other types of data can be sent over the SMS. The current SMS standards also allow segmentation of
messages that are too long to fit into a single message. Finally SMS is no longer only linked to GSM,
but is also available for the more recent protocols 3G and 4G protocols.

Figure 5: Call control scenario over GSM

The figure 5 show us a list of signaling messages for mobile phone during dispatch a voice call via
GSM, and the decoding part of the “Release” signal extracted by XCAL tools software.

Figure 6: Short message service scenario over GSM

In figure 6 a list of signaling messages for mobile phone during dispatch an SMS via GSM, and the
decoding part of the “CP Data” signal extracted by XCAL tools software.
13
2.1.2. GSM layer 3 message format
In the GSM protocol, all the messages sent on layer 3 have a standard message layout. The standard
layout of the message is the main topic of this section. The GSM Layer 3 messages consist only of bits
string of finite length. The bits are usually ordered in groups of eight, called an octet. The bits in an
octet are numbered from right to left as 1 to 8 with bit 8 being the most-significant bit [6].

Figure 7: GSM layer 3 message structure

Every Layer 3 message consists of at least two octets which form the header of the message.

 The first field or header, consisting of 4 bits of the first byte, is a protocol discriminator (PD) code
that indicates the type of protocol the message belongs to (i.e., CC or call related SS, MM, RR,
SMS, or non-call related SS). PD values are unique and specified below for GSM Layer-3 modules:

- Call control (CC) messages - 0011 (0x3)

- Mobility Management (MM) messages- 0101 (0x5)
- Radio Resource management messages- 0110 (0x6)

 The next field of 4 bits is a transaction identifier (TI) or skip indicator. For every CM message, the
TI identifies the particular CC transaction that is taking place within the CM sublayer. For both
MM and RR connection messages the field is set to all zeros (0000).

 The Message Type is 8 bit that identifies the type of message sent for example channel request,
paging request or response etc.

 Most Layer 3 messages do not only contain a header, but also transmit data to the receiving party.
This is done using the message body. Data in the body is represented in Information Elements
(IEs).

14
2.2. UMTS and LTE layer 3 protocols
In the UE- UMTS and LTE protocols architecture there is two concepts, the access stratum (AS) and
the non-access stratum (NAS), where the stratum in general represent the procedures for exchanging
information from both the signaling information and the user information (payload or useful data)
between the UE and the network core.

Figure 8: UE – UMTS layer 3 protocol architecture

Figure 9: UE – LTE layer 3 protocol architecture

15
2.2.1. Channelization
The information that flows from different types of protocol are known as channels and signals. LTE
and UMTS uses different types of channel and they have the same role [7]:

 Logical Channels: These channels define the data-transfer services offered by the MAC layer.
Data and signaling messages are carried on logical channels between the RLC and MAC protocols,
distinguished by the information they carry.

Firstly, logical traffic channels carry data in the user plane, while logical control channels carry
signaling messages in the control plane.

In the logical control channels we can found for example, the Common Control Channel (CCCH)
used for random access information, e.g. for actions including setting up a connection.

And we can found the Dedicated Control Channel (DCCH) used for carrying user-specific control
information, e.g. for controlling actions including power control, handover, etc.…

 Transport Channels: how and with what type of characteristics the data is transmitted over the
air, e.g. what are encoding, interleaving options used to transmit data. Data and signaling messages
are carried on transport channels between the MAC and the physical layer, distinguished by which
the transport channel processor manipulates them (DL, UL).

In the UL transport channels we can found for example the: Uplink Shared Channel (UL-SCH)
main channel for uplink data transfer. It is used by many logical channels. Also we can found the
Random Access Channel (RACH) used for random access requirements.

In the DL transport channels we can found for example the: Downlink Shared Channel (DL-
SCH): This transport channel is the main channel for downlink data transfer. It is used by many
logical channels.

 Physical Channels: LTE physical layer has different channels defined on both uplink and
downlink, each with a predefined purpose. These physical channels are fed using the transportation
channels of higher layers.

In the UL physical channels we can found for example the: Physical Uplink Shared Channel
(PUSCH): This physical channel found on the LTE uplink is the Uplink counterpart of PDSCH

16
2.2.2. Access stratum protocol (AS)
The access stratum responsible for carrying information (handover, ciphering/compression, Radio
resource management) over the wireless portion of the network. It is for dialogue explicitly between
the mobile equipment and the radio network [8].
- The Access Stratum in UMTS consists of PHY, MAC, RLC and RRC protocols.

- The access stratum in LTE user plane consists of PHY, MAC, RLC and PDCP protocols, and in
the control plane it consists of PHY, MAC, RLC, PDCP and RRC protocols.

This research only focus on the RRC protocol, where this finally used in UMTS and LTE Air interface,
and exists between UE and eNB and also exists at the IP level. The RRC have many services and
among of those services:

- Broadcast of system information related to the non-access stratum and to the access stratum.
- Establishment, maintenance and release of an RRC connection between the UE and E UTRAN.

To make the encoding and decoding idea very simple, we decide to start learning the decoding in the
establishment phase, where we have many things commune between LTE and UMTS like the RRC
connection request.

2.2.2.1. RRC establishment

The RRC connection establishment could be trigger by the UE, in case when the end-user starts an
application to browse the internet, or to send an email.

Similarly, the RRC connection establishment could be trigger by the UE in case the UE moves into
tracking area and has complete tracking area update signaling procedure.

This could be used to permit the transition of incoming SMS or notice of incoming calls.

The RRC connection establishment for LTE is relatively simple compared to RRC connection
establishment for UMTS where:

- In the case of LTE, the initial Non-Access Stratum (NAS) message is transferred as part of the
RRC connection establishment procedure. In the case of UMTS, the initial NAS message is
transferred after the RRC connection establishment procedure. The approach used by LTE helps
to reduce connection establishment delay.

17
 Figure 10: RRC connection establishment

2.2.2.2. IE of RRC connection request

Information Elements
UE Identity CHOICE
S-TMSI
Random Value
Establishment cause CHOICE
Emergency
High Priority Access
Mobile Terminating Access
Mobile Originating Signalling
Mobile Originating Data

Table 1: RRC connection request structure

The rrcConnectionRequest have this information [9]:

- UE identity (TMSI or Random Value): TMSI is used if UE has previously connected to the same
network. With TMSI value, UE is identified in the core network. Also contain the Random value
is used if UE is connecting for the very first time to network.

- Connection establishment cause: This shows the reason why UE needs to connect to network.

18
 Figure 11: LTE signalling messages

This figure showing us a list of signaling messages for mobile phone during dispatch an internet
connection via LTE, and the decoding part of the “LTE rrcConnectionRequest” extracted by XCAL
tools software.

2.2.3. Non access stratum protocol (NAS)

The NAS is a functional layer in UMTS and LTE wireless telecom protocol stacks between the core
network and mobile equipment. It is for dialogue between the mobile equipment and core network
nodes [10].

Examples of NAS messages include Update or Attach messages, Authentication Messages, Service
Requests and so forth. Once the User Equipment (UE) establishes a radio connection, the UE uses the
radio connection to communicate with the core nodes to coordinate service.

19
This NAS have two roles [10]:

- Mobility management in UMTS and named EPS mobility management (EMM) in LTE.

For example in UMTS the mobility for the NAS is the management of authentication, updating of
the location and attachment to the network. These are the MM protocol: Mobility Management for
circuit switching and GMM GPRS Mobility Management for the packet switching part.

- Session Management in UMTS and named EPS Session Management (ESM) in LTE.

For example the call control management layer called Call Control -CC- only for the 3G network
(since the 4G network is only an IP network). This sublayer only concerns the management of calls
in circuit switching that is to say the establishment, maintenance and release of calls from the
circuit domain.

2.2.3.1. UE- NAS UMTS

In UMTS the Non Access Stratum is divided based on circuit switched (CS) and packet switched (PS)
functionalities also they differently between control and user plane [8]:

- For UMTS CS control plane stack functions it consists of CM (connection management) and MM
(Mobility Management) layers. CM layer takes care of CC (Call Control), SM (supplementary
Services) and SMS (Short Message Service).

For UMTS CS user plane stack NAS part do not include CM and MM layers but it includes
application data layer protocol end to end (between UE-NodeB-RNC-MSC-Remote users).

- For UMTS PS control plane stack PS functions it consists of SM (session Management) and GMM
(GPRS Mobility Management) layers.

For UMTS PS user plane stack, AS part incorporates PDCP (Packet Data Convergence) and NAS
part incorporates packet protocol data (IP/PPP/..) and packet data applications (FTP/HTTP/..).
PDCP does compression of IP headers, it may or may not exist in the UMTS protocol stack.

 The circuit switching part of UMTS based on the GSM network protocols, where they both use the
same signaling messages during any circuit procedure, i.e. the "CP Data" signal in the "SMS"
sublayer of the connection management "CM" protocols.

20
 Figure 12: Short message service scenario over UMTS

The figure 12 show us a list of signaling messages for mobile phone during dispatch an SMS via
UMTS, and the decoding part for the “SMS Message- CP Data” signal extracted by XCAL tools
software.

Figure 13: GPRS mobility management scenario over UMTS

The figure 13 show us a list of signaling messages for mobile phone during dispatch a voice call via
UMTS, and the decoding part for the “cellUpdate” signal.

21
 Chapter 3. Existing decoder

The idea of our decoder named “Netprotool” born according to the existing decoding tools, like the
online web decoding and some software like XCAL, TEMS, Nemo, Wireshark.

3.1. Online web decoding

The online web decoding from the Marben or “objective systems” companies have both the same
functionality, were their products offers online ASN.1 decoders which allow easy decoding and
visualization of ASN.1 encoded data. Just supply the data in binary or hexadecimal format to get the
output in XML [11].

Figure 14: XML decoded data for RRC-DL-DCCH using 3GPP UMTS ASN.1 decoder from
Marben
22
So where this input data came from? This input data it should be extracted from specific tools likes
XCAL or TEMS…etc. This is an example based on the response of “objective systems” company,
about the input data.

Let we suppose that we have this encoded ASN.1 message for RRC connection release extracted by
XCAL tools.

Figure 15: Canonical HEX dump for RRC connection request extracted by XCAL

The question is, what we should extract from this encoded data to use it in the online web decoding?
And according to answers of the support team of the “objective systems” company, we need to that:

- Discard the title line (i.e. the first line)

- Extract what is after the 5 digit byte index and before the ASCII code starts.

So for the first line, we would have: 02 09 A0 01 16 00 38 07 00 40 06 05 00 2A 22 55 and for the

2nd, you would just have 11 00.

3.2. Wireshark
The Wireshark is perhaps one of the best open source packet analyzers available today. It is used for
network troubleshooting, analysis, software and communications protocol development, and
education. The Wireshark installer includes “WinPcap” library which is required for packet capture.
If you don’t have WinPcap installed you won’t be able to capture live network traffic but you will still
be able to open saved capture files. By default the latest version of WinPcap will be installed [12].

 To start working with Wireshark, we need a specific tools or hardware to capture the radio interface
into a .pcap file (e.g.: I believe Qualcomm QXDM can do it, and some vendor eNodeBs can do it).

Because a commercial USB modem will only provide a standard network interface and will never
allow you to capture LTE packets (USB modem won't work though because the information it
passes to the computer is normal PPP traffic).

For example; the best tools used to capture the GSM signaling messages are RTL-SDR or Hack-
RF tools; it’s an open source hardware and software. Also as another tool, we can use the 3GPP
decoder offline software.

23
 Figure 16: Capturing result for LTE-RRC.CCH using Wireshark

3.2.1. Sniffing GSM traffic with gr-gsm method using RTL-SDR

SDR is a radio components such as modulators, demodulators and tuners are traditionally implemented
in hardware components. The advent of modern computing allows most of these traditionally hardware
based components to be implemented into software instead. RTL-SDR is a very cheap “software
defined radio” that uses a DVB-T TV tuner dongle based on the RTL2832U chipset [13].

The RTL-SDR frequency range, dependent on the particular tuner variant used in the dongle, and the
particular implementation. Where the minimum frequency range can be 22 Mhz and the maximum is
2200 Mhz.

24
The RTL-SDR can be used for decode unencrypted digital voice transmissions, Analyze and sniffing
cellular phone GSM signals using Linux based tools GR-GSM that will decode GSM packets [14].

The aim is to provide set of tools for receiving information transmitted by GSM equipment/devices.

1. The easiest way to install gr-gsm is to use Pybombs. Pybombs will automatically install gr-gsm,
and all the required dependencies including GNU Radio.

$ sudo apt-get update

$ sudo apt-get install git python-pip
$ sudo pip install PyBOMBS
$ sudo pybombs prefix init /usr/local -a default_prx
$ sudo pybombs config default_prefix default_prx
$ sudo pybombs recipes add gr-recipes git+https://github.com/gnuradio/gr-
recipes.git
$ sudo pybombs recipes add gr-etcetera git+https://github.com/gnuradio/gr-
etcetera.git
$ sudo pybombs install gr-gsm
$ sudo ldconfig / many operating systems might not know where to look for new libgrgsm
library. In order to update cache of links to new libraries

2. Plug in the RTL-SDR then run grgsm_livemon by typing grgsm_livemon at the terminal. A new
window should open.

3. In the new window tune to a GSM downlink frequency which you determined while browsing in
SDR# and set the gain appropriately.

4. Start Wireshark by using sudo Wireshark -k -Y ‘!icmp && gsmtap’ -i lo which will automatically
start Wireshark in the loopback mode with the gsmtap filter activated. You may get an error when
opening Wireshark but this can be ignored.

5. You should now see the GSM data scrolling along in Wireshark.

25
 Figure 17: grgsm_livemon tools for calibrating the frequency of the RTL-SDR

Figure 18: Wireshark use RTL-SDR and gsmtap filter for detecting radio messages
26
3.2.2. 3GPP decoder
The 3GPP Decoder is an offline open source uses Wireshark to decode LTE, UMTS and GSM radio
messages support only windows OS and it will be in upcoming days for linux OS[15].

RAT Message/PDU

LTE RRC BCCH.BCH RRC BCCH.DL.SCH RRC DL.CCCH RRC DL.DCCH RRC
PCCH RRC UL.CCCH RRC UL.DCCH NAS EPS
RLC-AM/ RLC-UM/ NAS/ RRC BCCH.BCH/ RRC BCCH.FACH/ RRC
UMTS DL.CCCH/ RRC DL.DCCH/ RRC DL.SHCCH/ RRC MCCH/ RRC MSCH/ RRC
PCCH/ RRC UL.CCCH/ RRC UL.DCCH/ RRC UL.SHCCH/ RRC SIs (SIBs and
MIB)
GSM GAN TCP/ GAN UDP/ GSM CCCH/ GSM SACCH/ LLC/ NAS/ SNDCP
SNDCPXID

Table 2: Decoding possibility of the 3GPP decoder

Figure 19: Decoding test for UMTS NAS messages

27
3.3. XCAL decoder
The XCAL is real-time software-based solution for wireless network optimization and performance
measurement. XCAL collects Layer 1, 2, and 3 messages, and TCP/IP packets from both the air and
data interface of all commercially available technologies (GSM, GPRS, EDGE, UMTS, HSDPA, and
HSUPA). XCAL allows several mobiles to interface simultaneously with different technologies and
provides an ideal solution for measuring both voice and data service performance. XCAL support only
for window OS [16].

Figure 20: This screenshot show us the LTE signaling messages extracted by XCAL

Note the Figure 20 I received from the Accuver support team because the Accuver that I have is an old
version and not supporting LTE.

The main idea behind XCAL application is to capture data packets coming from DM (Diagnostic
Monitor) port of RF Modem of the device, but not only – collect data from OS, TCP/IP packets, etc.
For example, LG G5 H850 smartphone includes chipset Qualcomm Snapdragon 820 with LTE Modem
Snapdragon X12 (LTE Category 13 for downlink). XCAL link would be with Snapdragon X12 LTE
modem directly.

28
The way XCAL “talks” with connected devices is through available interfaces. The most common are
QMICM (Qualcomm MSM Interface Connection Manager) for QC (Qualcomm) commands, AT Port
for AT commands and ADB (Android Debugging Bridge) for ADB Commands.

In the Android smartphone, the most common communication protocol would be ADB for QoS
(Quality of Service) app installed on the smartphone. Then “wake-up messages” send it from Xcal to
Android OS would be ADB messages like Airplane Mode OFF/ON (Detach/Attach to network).

The RRC information collected from RF modem is CSN.1/ASN.1 cyphered and XCAL needs to
decode it. So the Hex shows original information captured for (the LTE rrcConnectionRequest) and
Detail window on the right shows decoded info. Also, the original message L3 Data in Hex.

29
 Chapter 4. Encoding methodology

Abstract-In the 3GPP UMTS and LTE specifications, different encoding/decoding rules are specified
for different layer 3 (L3) protocol modules when transmitting/receiving message PDUs, multiple
representations are specified for the various message protocol data units. For example, RRC messages
are represented in abstract syntax notation (ASN.l) format.

Whereas the messages of other L3 protocol modules where the Non access stratum like CC, MM, SM,
GMM, SMS are represented in tabular formats [17].

4.1. Protocol definition

A computer protocol can be defined as: A well-defined set of messages (bit-patterns or - increasingly
today - octet strings) each of which carries a defined meaning (semantics), together with the rules
governing when a particular message can be sent.

However, a protocol rarely stands alone. Rather, it is commonly part of a "protocol stack", in which
several separate specifications work together to determine the complete message emitted by a sender,
with some parts of that message destined for action by intermediate (switching) nodes, and some parts
intended for the remote end system.

Protocols can be specified in many ways. One fundamental distinction is between character-based
specifications versus binary-based specification [18].

 Character-based specification: the protocol is defined as a series of lines of ASCII encoded text.

- Binary-based specification: the protocol is defined as a string of octets or of bits. For binary-
based specification, approaches vary from various picture-based methods to use of a separately
defined notation with associated application-independent encoding rules. This is the approach
taken with ASN.1 Abstract syntax:

- It enables designers to produce specifications without undue concern with the encoding issues;

- Also permits application-independent tools to be provided to support the easy implementation of

protocols specified in this way;

- Moreover, because application-specific implementation code is independent of encoding code, it

makes it easy to migrate to improved encodings as they are developed.

30
4.2. Abstract syntax notation (ASN.1)
ASN.1 was first standardized in 1984 by the CCITT now called ITU-T under the name "X.409
Recommendation" used for describing the structure of data carried by messages exchanged between
communicating entities, is widely used in many forms of digital communications including
telecommunications, although used in applications as diverse as parcel tracking, power distribution
and biomedicine.

A little later, ISO chose to adopt this notation and split this recommendation into two separate
documents: the abstract syntax (ASN.1) and the encoding rules (BER). In 1985, the CCITT decided to
collaborate with ISO on these two documents [19].

4.2.1. ASN.1 encoding rule

ASN.1 has several alternative concrete syntaxes as defined in the ITU-T X.690 series.

- Where the abstract syntax is the form that would normally appear in a protocol standard and is
used to describe data structures at the level of human readability.

- And the concrete syntax defines the specific set of encoding rules used to convert the abstract
form to the actual stream of bits that is sent over a communication media [19].

Typical encoding rules are Basic Encoding Rules (BER) or more recently the PER (Packed Encoding
Rules), which prove useful for applications that undergo restrictions in terms of bandwidth-constrained
wireless industry, and XML support for easy use of common Web browsers, DER Distinguished
Encoding Rules, Canonical encoding rule.

These encoding rules describe how the values defined in ASN.1 should be encoded for transmission
(i.e., how they can be translated into the bytes 'over the wire' and reverse), regardless of machine,
programming language, or how it is represented in an application program. An ASN.1 definition can
be readily mapped (by a pre-run-time processor) into a C or C++ or Java data structure that can be
used by application code, and supported by run-time libraries providing encoding and decoding of
representations in either an XML or a TLV format, or a very compact packed encoding format.

The ASN.1 1990-release is no longer available. Presented during the January 1999 ASN.1 meeting,
the encoding control notation (ECN) developed and maintained by ITU-T as ITU Recommendation
X.692 allows specifiers to define their own encoding rules by referencing standardized encoding rules
and modifying some of their characteristics, or even to set up completely new ones.

31
4.2.2. ASN.1 module case study
This is an example ASN.1 module defining the messages (data structures) of a fictitious Foo Protocol
[20]:

Figure 21: ASN.1 module named FooProtocol

This is a particular message that complies with the Foo Protocol and that will be sent to the receiving
party (protocol data unit (PDU)) is:

Figure 22: ASN.1 message based on the FooProtocol

Let us suppose a company owns several sales outlets linked to a central warehouse where stocks are
maintained and deliveries start from. The company requires that its protocol have the following
features [19]:

- the orders are collected locally at the sales outlets ;

- they are transmitted to the warehouse, where the delivery procedure should be managed ;
- An account of the delivery must be sent back to the sales outlets for following through the client's
order.

32
 Figure 23: Two Examples of ASN.1 module

4.3. CSN.1
Although their acronyms are similar, CSN.1 is substantially different from ASN.1 [21].

 ASN.1 defines an abstract data structure, in other words, an ASN.1 specification tells you, for
example, that we have a structure with some fields in it, or a union, an array and so on. In ASN.1
we describe our data structure as we do when we are declaring C struct.

- When we need to actually send the data over the network, we follow the encoding rules we
have chosen. These encoding rules, like BER o PER, tell us that a structure is always coded in
a given way, an integer is always coded in another way and so on.

- Therefore any ASN.1 tools can easily generate a C data structure and some C code able to take
a BER or PER coded binary stream and decode it into that C structure.
33
 The CSN.1 formal language has been introduced by 3GPP at the end of the 90's to describe mostly
the encoded format of GSM L3 messages. Before that, those encoding were expressed only by
mean of various unformal tables and text parts, describing the meaning of each bit.

- The goals of CSN.1 were to have a unified language for all the description, describe the
encoding formally, and encourage the creation of automatic encoding/decoding generators.

- CSN.1, instead, defines at bit-level the encoded stream. A CSN.1 definition says, for example,
that we expect a 1 followed by 8 more bits or a 0 followed by 4 bits and another 0:
< my data > ::= 1 <x: bit(8)> | 0 <y: bit(4)> 0;

- Most of the CSN.1 tools read the CSN.1 specification file and produce a CSN.1 parser; this
parser, once compiled, reads the encoded binary stream and when it recognize some valid
elements in it invokes a user defined callback function.

- In other words, it generates code that will say to you: hey, I found the 1 followed by the 8 bits
you were expecting: the 8 bits are 11001001; do whatever you like. In other words, the data
structures need to be deduced from the encoded data by reverse-engineering the CSN.1 code
and try to guess the original structures.

4.4. Encoding methodology of CC and MM protocol

This is an example extracted from IEEE research paper, about how ASN.1 and ECN module used to
make the code platform and OS independent. This section covers the encoding of the top level of the
message, the message header [17].

Figure 24: requirement for UMTS layer3 ciruit switch

34
 Figure 25: ECN and ASN.1 modules for message headers

In the above example:

- The 'Mobility Management' and 'Call Control' are two of the protocol types and will contain all the
messages associated with each particular protocol.
- The message type value is encoded as a tag and it produces the identification handle, 'Tag8'.
- The 'bit8-tag' is used to encode the message type value and the message type value itself will be
the unique 'Tag8' value of each message.
- The 'choice8' is the object that specifies that the message chosen from that protocol type is
determined by value of handle 'Tag8'.
- Similarly, the 'choice4' and 'Tag4' determine the protocol chosen.
- The 'Tag4' is the value of the protocol discriminator.

35
4.5. ASN.1 compiler
The ASN.1 allows to describe complex data structures independently of any programming language,
by taking these ASN.1 specifications and produce a set of target language files (i.e. C) which would
contain the native type definitions for these abstractly specified structures, and also generate a code
which would perform the conversions of these structures into/from a series of bytes [22].

4.5.1. ASN.1 free open source compiler

The ASN.1 free open source compiler is a tool for creating data encoders and decoders out of formal
ASN.1 specifications.

 Let’s suppose that we want to convey a certain structure including a couple of integers and
variables between computers. Thus, by using ASN.1 the structure will described be as follows:
CertainStructure ::= SEQUENCE {
tag VisibleString,
val1 INTEGER,
val2 INTEGER OPTIONAL,
reals SET OF REAL
}END

 The compiler would read this ASN.1 definition and produce the following C type:
typedef struct CertainStructure {
VisibleString_t tag;
long val1;
long *val2;
A_SET_OF(double) reals;
} CertainStructure_t;

 This is how the network will receive the structure:

CertainStructure_t *cs = 0;
ber_decode(0, &asn_DEF_CertainStructure, &cs, buffer, buffer_length);
cs->val1 = 123; /* Modify the contents */
der_encode(&asn_DEF_CertainStructure, cs, write_handle, 0);

 And here's how easy the contents of this structure can be printed out in XML format:
// xer_fprint(stdout, &asn_DEF_CertainStructure, cs);
<CertainStructure>
<tag>This is a random tag</tag>
<val1>123</val1>
<reals>
<REAL>3.14159265</REAL>
<REAL><MINUS-INFINITY/></REAL>
<REAL>2.7182818284</REAL>
</reals> </CertainStructure>

36
4.5.1.1. Quick start with ASN.1 compiler
For example, let we suppose that we create a file named rectangle.asn1 with the following contents
[23]:
RectangleTest DEFINITIONS ::= BEGIN
Rectangle ::= SEQUENCE {
height INTEGER, -- Height of the rectangle
width INTEGER -- Width of the rectangle }
END

 After building and installing the compiler, the asn1c command used to compile the ASN.1
modules1 asn1c <modules.asn1> after that, the asn1c compiler produces a number of files:

- A set of .c and .h files for each type defined in the ASN.1specification. These files will be named
similarly to the ASN.1 types (i.e. Rectangle.c and Rectangle.h for the RectangleTest ASN.1).the
following C type for example:
typedef struct Rectangle_s {
long height;
long width ;}
Rectangle_t;

- A set of helper .c and .h files which contain the generic encoders, decoders and other useful
routines.

- A converter -sample.c file containing the int main() function with a fully functioning decoder. It
can convert a given PDU between BER, XER and possibly PER (if -gen-PER option to asn1c was
in effect). At some point you will want to replace this file with your own file containing the int
main() function.

 The data encoded using the XER rules can be subsequently decoded using the xer_decode() API
call:
Rectangle_t *
XML_to_Rectangle (const void *buffer, size_t buf_size) {
Asn_dec_rval_t rval;
Rectangle_t *rect = 0; /* Note this 01! */
rval = xer_decode (0, &asn_DEF_Rectangle, (void **)&rect, buffer, buf_size);
if (rval.code == RC_OK) {
return rect; /* Decoding succeeded */ }
else {
/* free partially decoded rect */
asn_DEF_Rectangle.free_struct (&asn_DEF_Rectangle, rect, 0); return 0 ;}
}
 To invoke the XER decoder in a manner similar to asn_fprint(), use the xer_fprint() call:
xer_fprint(stdout, &asn_DEF_Rectangle, rect);

37
For more information about how encoder decoder work in ASN.1 Compiler check this link [23]

The ASN .1 open source compiler already have a list of built in existing decoder in examples directory:

Figure 26: Existing decodder in ASN.1 open source compiler

38
To build own RRC encoder we need to follow the step in the part 4.5.1.1 but we need the ASN module
for it! And this is how we can get the RRC module that we need from this website:
http://www.3gpp.org/ftp/Specs/tm-info/25331.htm

And in case we need to dump the content of a PER-encoded RRC protocol data we need to run this
command ./ rrc-dump –p DL_DCCH-Message message.per

39
 Chapter 5. Netprotool decoder

To start live decoding at the first time we want an application not far from the 3GPP offline decoder.
A GUI application implemented on linux embedded system, as a first scenario the embedded system
is a Raspberry PI connected to a radio equipment like RTL-SDR or Samsung mobile phone or
embedded module (3G/LTE Dev Kit from SIXFAB embedded with a mini PCI express module from
Quectel) and the decoding principe based on the Wireshark installed on the Raspberry PI by using
Tshark command line inside the python script. Where Tshark is a terminal oriented version of
Wireshark designed for capturing and displaying packets when an interactive user interface isn’t
necessary or available. It supports the same options as Wireshark.

And for facility we have another scenario (Scenario 2) by using a linux Dev Kit from SIERRA
embedded with a Sierra MC77100 module named (Airprime MC Series Dev Kit). Note that our
decoding work, is based only on the Raspberry PI, but at the end of this report there is a small
introduction about the Airprime MC Series Dev Kit but the decoding part that based on it still not
complete.

Also there is third scenario, totally different from the first two scenarios, without using radio capture
this scenario created according to the idea of my coordinator Mr. Duclos Laurent, where he want from
me to check it.

5.1. GUI application

Figure 27: Netprotool application

This application programmed in Python language, help the user to extract the decoded radio messages
directly by choosing from the menu bar the radio message type according to the mobile technology

40
(LTE or UMTS or GSM), where the original captured information will appear in the “CSN.1/ASN.1
original cyphered message” and the decoded information will be in the “Decode message”.

Figure 28: Python code of the Netprotool application

41
5.2. Netprotool – scenario 1
In our work, one of three method was implemented on the Raspberry PI to capture and decode the
radio message, one by using the diag parser method, and a second by using the Xgoldmon method
and the last one by using GR-GSM method. The last two methods not tested because we didn’t have
the specific tools for it.

But before we start in these methods i want to make a small introduction about the raspberry PI.

 The Raspberry Pi is a series of small single-board computers developed in the United Kingdom by
the Raspberry Pi Foundation to promote the teaching of basic computer science in schools and in
developing countries. The original model became far more popular than anticipated, selling outside
of its target market for uses such as robotics.

Figure 29: Raspberry PI interfaces

42
5.2.1. Diag-Parser method
Parse the Qualcomm DIAG format and convert 2G, 3G and 4G radio messages to Osmocom GSMTAP
for analysis in Wireshark [24].

The Qualcomm DIAG it is the Qualcomm diagnostics interface built into many Qualcomm based
chipsets. The general idea is that there is some physical transport medium between the chipset/modem
and an external PC, and the PC can request certain diagnostic information to be sent via that physical
transport. Initially, this transport was a dedicated serial port/UART. Later, this became a virtual serial
port over USB.

The Osmocom is an umbrella project regarding open source mobile communications. This includes
software and tools implementing a variety of mobile communication standards, including GSM,
DECT, TETRA and others.

The GSMTAP is a pseudo-header that is used to transport frames from the GSM air interface (Um
interface) inside UDP/IP packets

A pseudo-header is an additional header in front of a protocol message, which is not part of the actual
protocol.

In our work the diag parser method was tested by using a 3G/LTE Dev Kit from SIXFAB embedded
with a mini PCI express module from Quectel.

So what is the mini PCI express module? The Mini PCIe express EC25 module in our case, is a card
manufactured by Quectel, is a series of LTE category 4 module adopting standard PCI Express
MiniCard. It is optimized specially for M2M and IoT applications, and delivers 150Mbps downlink
and 50Mbps uplink data rates. EC25 Mini PCIe supports location technology Gen8C Lite (GPS,
GLONASS, BeiDou, Galileo and QZSS) [25].
FDD-LTE B1/B3/B5/B7/B8/B20
TDD-LTE B1/B40/B41
3G WCDMA B1/B5/B8
GSM/EDGE B3/B8
Embedded GNSS Optional
Region EMEA, Korea, Thailand, india

Table 3: Quectel EC25-X specifications

43
Where this 3G/LTE shield include QUECTEL EC25 Mini PCIe module, communicate with the
Raspberry PI via UART pins but speed is very low. So for that a USB data cable should connect at the
same time for communicate to the shield and connect to the internet. Because LTE connection needs
high-speed communication, also offering extra power.

Also the LTE shield have possibility to connect directly to computer via USB cable but first we should
install the driver for it from the QUECTEL.

Figure 30: Raspberry PI conncet LTE shield

Figure 31: LTE shield interface connectevity with the Raspberry PI

44
5.2.1.1. Configuring the 3G/LTE shield
1. Connect Raspberry Pi to Internet via Wi-Fi or Ethernet [26]. Once Raspberry Pi is connected,
update Raspberry Pi by following command: sudo apt-get update.

2. Quectel Module support is to be added to the kernel, since Raspbian Jessie Kernel doesn’t support
Quectel EC25/ UC20 modules.
a. Install rpi-update: sudo apt-get install rpi-update
b. Update Raspberry Pi Kernel using following command: sudo rpi-update
c. Once updated Reboot the device: sudo reboot
d. Connect USB Cable to shield from Raspberry Pi, then use ls /dev and check if ttyUSB3
is available.
3. The EC25/EC21 module provides a PPP server for application, and the application side provides a
PPP client for the module to provide protocols such as TCP/IP, HTTP, etc. When PPP connection
has been set up, the IP packet flow from the application side will be transmitted to Internet through
EC25/EC21 module.

In Linux system, PPP dial-up is implemented by PPPD and CHAT. It’s necessary to install PPPD
and CHAT before establishing PPP connection. So for that we need to create a script file that can
divide into three scripts named as:
“quectel-ppp”, “quectel-chat-connect” and “quectel-chat-disconnect” in “/etc/ppp/peers”
directory.

This script is a protocol procedure written by the Quectel, so we need to download the ppp-
creator.sh script.

- wget https://raw.githubusercontent.com/sixfab/rpiShields/master/tutorials/tutorial3/ppp
creator.sh
- chmod +x ./ppp-creator.sh
- sudo ./ppp-creator.sh HOLOGRAM ttyUSB3

 HOLOGRAM is the APN. As for example, APN for orange Mobile is orange. ttyUSB3 is the
connection.

 If we are using UART of Raspberry Pi 3 then use ttyS0 instead of ttyUSB3 or for other versions
of Raspberry Pi use ttyAMA0.

 The content of the ppp-creator.sh shown as below:

45
 Figure 32: Script for connecting to the network

Figure 33: Script for disconnect from the network

46
 Figure 34: Script for establishement the ppp connection

3. Now we need to disconnect the Raspberry Pi from Wi-Fi or Ethernet. And run this command to
establish the PPP connection: sudo pppd call gprs, sudo pppd call gprs&.

4. After that we need to check the status of shield and the IP address, type: ifconfig ppp0.

5.2.1.3. diag-parser setup

 Before start installing the diag-parser, we need to install first: autoconf, automake, libtool, pkg-
config, libtalloc, make, gcc on the Linux distribution [24].

git clone git://github.com/moiji-mobile/diag-parser

cd diag-parser
./build/build_local.sh
 To start capturing we need to run this command. /diag_parser -g 10.23.42.7 -i /dev/ttyUSB0.
Were the DIAG debug interface is on /dev/ttyUSB0 and Wireshark running on a system with the
internal IPv4 address of10.23.42.7. This how we can use from parameters in the diag_parser:
-h: Display the help output
-g A.B.C.D: Send GSMTAP frames to A.B.C.D:4729
-p file.pcap: Write GSMTAP to PCAP file
-i: Initialize DIAG interface on the device
5.2.1.4. Result
The diag-parser method was tested on 3G, LTE shield for raspberry PI, where the real test for should
implemented on PCengines APU2 with Quectel EC20 and Quectel UC20. So for that our result was
null, where Wireshark not showing me any captured messages.

47
5.2.2. Xgoldmon method
Xgoldmon is a tool to convert the messages output by the USB logging mode of phones back to the
GSM/UMTS radio messages, so we can watch them in Wireshark. Xgoldmon uses libosmocore to
send the radio messages in GSMTAP format [27].

Before start explaining how to use the Xgoldmon method, it’s very important to know that the
Xgoldmon method only supported these devices with Intel/Infineon XGold baseband processor:
Samsung Galaxy S4 GT-I9500, Samsung Galaxy S3 GT-I9300, Samsung Galaxy Nexus GT-I9250,
Samsung Galaxy S2 GT-I9100, and Samsung Galaxy Note 2 GT-N7100.

5.2.2.1. Xgoldmon setup

 Before running Xgoldmon, firstly we need to activate the logging mode ("diag mode"): from the
phone application by entering *#9900# and set "Debug Level Enabled" to "HIGH". Then enter
*#7284# and set "USB" to "MODEM" and tap "SAVE and RESET".

- After that we should connect the phone via USB to the computer, a several new pseudo-tty devices
should appear in the /dev directory, were the second lowest number should be the logging port. On
Linux, if no other ttyACM* devices, it should be /dev/ttyACM1.

- The Xgoldmon tries to set proper serial attributes on the device if the "-s" option is specified. If
that fails, we can do that manually: stty 115200 pass8 raw -noflsh -F /dev/ttyACM1

 To run the Xgoldmon Usage: ./xgoldmon [-t <phone type>] [-l] [-s] [-i <ip address>] [-v] <logfile
or device>
-t: select 's4', 's3', 'gnex', 's2' or 'note2' (default: 's3')
-l: print baseband log messages
-s: set proper serial device attributes
-i: send gsmtap packets to given ip address (default: 'localhost')
-v: show debugging messages (more than once for more messages)

 In order to monitor the packages with Wireshark, something has to listen on that port: nc -u -l
4729.
 Then, in Wireshark, start a capture on the loopback interface. To see only the GSMTAP messages,
set this filter: udp.port==4729
5.2.2.2. Result
The Xgoldmon not tested because, I didn’t have the specific mobile phones to make the test.

48
5.3. Netprotool– scenario 2
In this scenario we used the Airprime MC Series Dev Kit, a linux board built in an application named
“Linux QMI SDK” include a mini PCI express MC7710 Airprime module card manufactured by
Sierra vendor. This MC7710 provides LTE, DC-HSPA+, HSPA+, HSDPA, HSUPA, WCDMA, GSM,
GPRS, EDGE, and GPS connectivity for portable and handheld computers, point-of-sale devices,
telemetry products and other machine-to-machine and vertical applications over several radio
frequency bands [28].

5.3.1 AirPrime MC Series Development Kit

Figure 35: Development Kit for MC Sierra module

Figure 36: Interface architecture of the AirPrime MC Series Development Kit [29]

49
5.3.2. Linux QMI SDK application
The QMI (Qualcomm MSM Interface) is a binary protocol designed to replace the AT command based
communication with modems. This protocol is used by some Sierra Wireless modules based on
Qualcomm chipsets. [30].

Where QMI came from?

Mobile-specific AT protocol ex-tensions have controlled mobile broadband modems thus far. Were
these AT protocol defined by the implementers of the mobile broadband technology standards (e.g.
the European Telecommunication Standards Institute, ETSI GSM 07.07, later 3GPP TS 27.007 1), or
by device vendors themselves (e.g. Qualcomm extensions for CDMA/EV-DO devices) [31].

These modems (i.e. Gobi modems) receive the logic (information) that was applicable to dial-up
modems, which includes the AT protocol. However, the establishment of a PPP2 session is necessary
to serve as an interface between computer and modem (or even the network itself).

Once the connection was increased (e.g. LTE/4G data rates), and newer technologies seemed to cross
between the device and the host computer (e.g. USB), manufacturers began to implement their own
new protocols to control mobile broadband devices. The AT+PPP pair, which is still available in most
of the devices, became a legacy approach. Mainly for systems, which do not talk to the new protocols
yet.

The Qualcomm MSM Interface (QMI) protocol developed by Qualcomm was newly implemented to
control mobile broadband modems. This can be used in Linux kernel based operating systems by two
mutually exclusive kernel drivers: ’GobiNet’ and ’qmiwwan’.

These two drivers have a different approaches to deal with the protocol; GobiNet is a complex driver
which implements within the kernel most of the core protocol logic. On the other hand, qmiwwan just
leaves all those tasks to user-space processes (therefore keeping the kernel bits as small as possible).

So what is AT command?

The AT commands (abbreviation attention command) is a set of series of short text strings (instruction)
which are combined together to produce complete commands for operations such as dialing, hanging
up, and changing the parameters of the connection and extracting information of many sorts [32]. The
majority of modems follow these command set which are typically known as AT commands

50
 Test Command AT+<x>=? This command returns the list of parameters and
value ranges set with the corresponding Write
Command or by internal processes
Read Command AT+<x>? This command returns the currently set value of the
parameter or parameters
Write Command AT+<x>=<…> This command sets the user definable parameter
values
Execution AT+<x> This command reads non0varible parameters
Command affected by internal processes in the GSM engine

Table 4: AT command use

Command Description
AT+CPIN=0000 Enter PIN code
AT+CPWD=”SC”,”old”,”new” Change PIN code from ‘old’ to ‘new’
AT+CLCK=”SC”,0,”0000” Remove PIN code
AT&V Status
ATI Status (Manufacturer, Model, revision, IMEI, Capabilities)
List available network 0-Unknows/ 2-Current/ 3-
AT+COPS=?
Forbidden, Longname, Shortname, Numerical-ID, “ACT”
Get signal strength Answer: +CSQ: <rssi (more=better)>/
AT+CSQ
<ber, less=better>
ATD*99# Dial access point
AT+CGDCONT=1,”IP”,
Defines PDP context
“access.point.name”

Table 5: Description for some AT command

 What is SDK?
SDK (software development kit), a programming package that enables a programmer to develop
applications for a specific platform. Typically an SDK includes one or more APIs, programming tools,
and documentation [33].

Application program interface (API) is a set of routines, protocols, and tools for building software
applications. An API specifies how software components should interact. Additionally, APIs are used
when programming graphical user interface (GUI) components. A good API makes it easier to develop
a program by providing all the building blocks. A programmer then puts the blocks together.

5.3.2.1. QMI SDK architecture

Starting from Linux QMI SDK 4 version, two different architectures can be adopted depending on
feature needs and constraints [30]:

- Lite APIs – this is a tiny version adapted to low memory footprint. This layer only manages
QMI message encoding (request) and decoding (response/indication) through function calls.
51
 - Full APIs – this is a more complete version adapted to less constrained environment. It comes
with some processes handling memory allocations, timers, and machine-state to provide
features such as: Modem detection/scanning, Modem mode management: application or boot-
hold (firmware download), QMI port multiplex for applications and scheduling, Modem
firmware update.

Figure 37: QMI SDK architecture

5.3.2.2. Configuration setup

1. Host setup [30]:
- Black listed the built-in drivers that can interfere with the SDK process’s execution by adding these
2 entries to the “/etc/modprobe.d/blacklist-modem.conf” file and restart the host.
blacklist qcserial
blacklist qmi_wwan

- Remove “Modem Manager” application and restart the host.

#sudo apt-get remove modemmanager
#sudo killall -9 modemmanager
#sudo reboot

52
2. System dependencies:
sudo apt-get install build-essential make gcc
sudo apt-get install linux-headers-`uname -r

3. Building and installing the drivers:

cd GobiSerial; make; sudo make install
cd GobiNet; make; sudo make install
sudo modprobe GobiSerial [debug=Y]
sudo modprobe GobiNet [debug=Y]
4. Querying Drivers Versions:
modinfo GobiSerial
modinfo GobiNet
5. Unloading the Drivers:
sudo rmmod GobiSerial
sudo rmmod GobiNet
6. Enabling the drivers diagnostic messages:
echo 1 > /sys/module/GobiSerial/parameters/debug
echo 1 > /sys/module/GobiNet/parameters/debug
7. Verifying proper driver operation:
- Open terminal and type tailf /var/log/syslog.
- Plug in the Sierra Wireless device.
- Check /dev/ for existence of the following devices :
/ttyUSB0, /ttyUSB1 ttyUSB2
/dev/qcqmix where x is an integer starting at 0
/dev/qcqmiy where y is an integer starting at 0
8. Define compilation flag:
The flags below are defined for SDK compilation on all architectures. “-Wall -Werror -Wextra”
Specific architectures may have other flags defined.

5.3.2.3. Functionality
In our work we used only the LITE API. The Lightweight (or Lite) APIs allow developers to pack or
unpack QMI messages directly. Developers have to handle the QMI device (/dev/qcqmi#) read and/or
write. The packing demo is a utility that exercises most of these lightweight APIs [30].

 After the host setup configuration successfully done, we need to connect the QMI SDK to linux
PC using a dedicated USB 2.0 cable.

53
 For the packing demo, there is a software named Linux QMI SDK (SDK that was used is
SLQS04.00.00.bin) that we need to install. The QMI SDK software come with three tools: DM
Logging, RAM Dump and SQF Filter Tools.

Figure 38: Run packing demo sample app

Figure 39: Application to retrieve the module ID

 The DM Logging tool which was used as a part to see the radio layer3 signaling messages, include
DM script that was located in the SLQS04.00.00/tools/logging/dm/dmcapture.sh

 We need to run this script to generate a file in a .raw format, were this file carries DM filters to the
device and log raw DM packets for real-time analysis.

 But, this is not all to read the layer3 signaling radio messages. To analyze the raw data and filter
out the layer3 messages we need a Licensed Translator and QXDM tool to analyze it.
54
5.3.3. Result
The main idea from this scenario is to check if we can use this tools DM logging tool to capture and
decode radio message directly.

And after configuring this tools and installing all the necessary packages we can see that the DM
logging tool don’t have the ability to decode radio message.

So I decide it to complete on the 3g, LTE shield PI where there are finally have the same functionality.

55
5.4. Netprotool– scenario 3
In this scenario, we wanted to create a system used Raspberry PI connected only to a mobile phone.
The idea came from that “XCAL” analyzer may be send a specific message to the mobile phone over
USB, we named “WAKEUP” message, to push him to flow all his signalling message over the USB
into the “XCAL”. So, we decided to sniff all the data packets between them by using a specific software
called “USB sniffer”.

The functionality of this scenario divided to two test which should be done in the absence of network
connection on the phone:
Before Launch XCAL: 2 Test (Packet type) each one 30 second as length
After Launch XCAL: 2 test (Packet type) each one 30 second as length

1- First we decided to disconnect the mobile phone on any network, because we don't need to swim in
the radio signaling that coming from the mobile to the XCAL. Then connect the Phone to PC via USB
cable, where we have XCAL tools.

2- Then we need to make two sniffing test, each one of them contain two test (Packet type) during 3o
second for surety reason where “XCAL” need this time to execute, one before launching “XCAL”,
because we want to capture a pure data to analyze first and to compare with the result after launching
XCAL because according to idea of this scenario, “XCAL” should be send in this case the “WAKEUP”
message to the mobile phone.

In case we detecting the “WAKEUP” message, we put it in our “Python” script, to send it to mobile
phone connected to the “Raspberry pi” to push him to send all the radio signalling messages. And sure
the decoding of the message send it back from the phone will be based on Wireshark library.

To good understand this scenario we should have a knowledge background about universal serial bus
how it work. So what is universal serial bus and how it work?

5.4.1. Universal serial bus (USB)

USB is a used for connecting a variety of peripherals (devices) to a computer (Host) such as: pointing
devices, displays, and data storage and communications products [34].

A device attached to a USB system is assigned a number known as the "address". That specific device
uses the address while it is connected. It also contains a number of "endpoints", that are a collection of
bases and destinations for communications between the host and the device. Endpoints function in a

56
simplex mode, meaning that they are either an input or output, however cannot be both. For example,
a simplistic model of a keyboard could have a keypad as output endpoint, and the LED key lock display
as receiving endpoint.

Each USB devices has one of each of their 16 possible input and output endpoints kept as "zero
endpoints". Auto-detection and configuration is possible due to these zero endpoints when it is
connected, and are the only accessible endpoints until this occurs.

The host uses combination of the address, endpoint number and direction and software to determine
which "pipe" data is travelling. A pipe is a data path between the controlling software and endpoint,
for example the Keyboard LEDs and the BIOS routine that determines what LEDs should be lit. A
special pipe is defined to connect to the zero endpoints, and is called the Default Control Pipe.

5.4.1.1. USB Types of data transfers

To adjust to the different types of data that needs to travel across the USB, each pipe can be configured
as one of four transfer types [34].

Control Transfers: use in configuring, controlling, and checking the status of a USB device. The host
can also send commands or query parameters with control packets. A request is sent to the device from
the host, and appropriate data transfers follow in the appropriate pipes. The pipe used for this type of
data may be bidirectional, but uses the same numbered endpoint for each direction.

Bulk Transfers: a device like a printer, which receives data in one big packet, uses the block transfer
mode. A block of data is sent to the printer (in 64-byte chunks) and verified to make sure it is correct.
As the name suggests, the intended purpose is for transmitting large amounts of data.

Isochronous Transfers: A streaming device (such as speakers) uses the isochronous mode. Data
streams between the device and the host in real-time, and there is no error correction. This transfer
method uses unidirectional pipes with no error handling procedures.

Interrupt Transfers: a device like a mouse or a keyboard, which will be sending very little data,
would choose the interrupt mode.

5.4.1.2. How is data sent across the USB?

Data transmission in Universal Serial Bus occurs in a serial form. The actual data gets sent via
"packets". Each packet is a group of data with information concerning the source, destination and
length of the data, and also error detection information [34].

57
An IRP may require numerous packets to be sent, with each packet being the maximum possible size
except for the final packet. A built in mechanism within the USB can tell it when to expect full sized
packets.

Each packet is made up of a set of components called “fields” including the following:

- An eight bit "SYNC" synchronization field used by inputs to correct their timing for accepting data.
Part of this field is a special symbol used to mark the start of a packet.

- The 8 bit Packet Identifier (PID) which uses 4 bits to determine the type, and hence format, of the
packet data. The remaining 4 bits are a 1's complement of this, acting as check bits. Part of this
field determines which of the four groups (token, data, handshake, and special) that the packet
belongs to, and also specifies an input, output or setup instruction.

- An “address field” which gives the address of the function on the end of the pipe to be used.

- The 4 bit “endpoint field”, giving the appropriate endpoint which sends or receives the packet.

- A “data field” consisting of 0-1023 bytes.

5.4.2. Result
This scenario is only a study, my work on it was to put the first lines for it and to see if we can go
forward with it. But the truth is the USB sniffing tools is a very high pricet and we can’t use any kind
of free open source sniffing tools, were we need a clear data so the work on this scenario was stopped.

But i would like to mention for you how we should compare the results in case we have USB sniffing.
Fist we need to know that we will be interest in the Control transfer protocol and then we can make
the two test according to it.

- Test for 30s before launching XCAL

Control Transfers Test 1 Test 2
Pipe packet 00000002
Setup packet

Test for 30s after launching XCAL

Control Transfers Test 1 Test 2

Pipe packet 00000002
Setup packet

Table 6: How it can be the comparison between the two test

58
Conclusion
Although that we didn’t arrive during this training to the supposed result, but our work was very
important point to understand the project and lay the basic pillars and all the necessaries scenarios to
start in the project.

Also this internship gave me more information in the embedded system, related to the radio
telecommunication. Were i have much experience in the functionality of the embedded radio module
like (GSM module, 3G/ LTE module) and how can I configure it on linux system and how can extract
and send data using embedded module.

The theoretical part of the project, our research gives the reader a general overview in mobile network
technology focusing on the layer 3 protocols. Also This research introduce the most important
language to understand the functionality of the radio messages decoding, which is the ASN.1 language,
and how to create own personal radio message decoder using linux software like the open source
ASN.1 compiler.

For the practical part, many important tools in the decoding domain was used and introduced like
Actex, Wireshark, Online web decoding, offline decoder and what kind of methods can use to create
a real time decoder on linux system like raspberry PI and the Sierra Dev Kit.

59
List of abbreviation
MS: Mobile station
UE: User Equipment
GSM: Global System for Mobile Communications
UMTS: Universal Mobile Telecommunications System
LTE: Long-Term Evolution
GPS: Global Positioning System
SMS: Short Message Service
MMS: Multimedia Messaging Service
GPRS: General Packet Radio Service
EDGE: Enhanced Data rates for GSM Evolution
HSPA: High Speed Packet Access
OSI: Open Systems Interconnection
CS: Circuit Switched
PS: Packet Switched
NAS: Non Access Stratum
AS: Access Stratum
CM: Connection Management
MM: Mobility Management
SM: Session Management
GMM: GPRS Mobility Management
MAC: Medium Access Control
RLC: Radio Link Control
RRC: Radio Resource Control
PDCP: Packet Data Convergence Protocol
PHY: Physical layer
eNB: Evolved 3G base stations
E-UTRAN: Evolved UMTS Terrestrial Radio Access Network
TMSI: Temporary Mobile Subscriber Identity
HEX: Hexadecimal
ASCII: American Standard Code for Information Interchange
QXDM: QUALCOMM eXtensible Diagnostic Monitor
PPP: Point to Point
3GPP: 3rd Generation Partnership Project
60
OS: Operating System
CDMA: Code Division multiple Access
HSUPA: High Speed Uplink Packet Access
HSDPA: High Speed Downlink Packet Access
ASN.1: Abstract Syntax Notation one
CCITT: Consultative Committee for International Telephony and Telegraphy
ITU-T: International Telecommunication Union it coordinates standards for telecommunications.
CSN.1: Concrete Syntax Notation One
BER: Basic Encoding Rules
PER: Packed Encoding Rules
2G: Second Generation
3G: Third Generation
4G: Ford Generation
PCI: Peripheral Component Interconnect Express
UART: Universal Asynchronous Receiver Transmitter
USB: Universal Serial Bus
FDD: Frequency Division Duplex
TDD: Time Division Duplex
WCDMA: Wideband Code Division Multiple Access
M2M: machine to Machine
IoT: Internet of Things
SDK: Software Development Kit
API: Application Program Interface

61
References

[1] Orange S.A, URL:

https://ipfs.io/ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/wiki/France_T%C3%A9l
%C3%A9com.html

[2] 3gpp, URL:

http://www.3gpp.org/technologies/

[3] Tech-FAQ, «The OSI model », URL:

http://www.tech-faq.com/osi-model.html

[4] RF Wireless World, «GSM protocol stack- GSM Layer 3», URL:
http://www.rfwireless-world.com/Articles/gsm-protocol-stack-Layer3.html

[5] tutorialpoint, «GSM - Protocol Stack », URL:

https://www.tutorialspoint.com/gsm/gsm_protocol_stack.htm

[6] Briniod Hond, Radboub University NIJMEGEN « Fuzzing the GSM protocol », Master thesis, pp.51-56,
Netherlands, 29 July 2011, URL:
https://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjT4
7v22r7VAhWJuhoKHbvKDnwQFggoMAA&url=http%3A%2F%2Fwww.ru.nl%2Fpublish%2Fpages%2F76
9526%2Fscriptie-brinio-final-brinio_hond.pdf&usg=AFQjCNEcbKRO4dDGCwOc1qboJDFNuoJYzQ

[7] Techplayon, «LTE channels: Logical, Transport and Physical Channels Details and Mapping », August 3
2017, URL:
http://www.techplayon.com/2411-2/

[8] RF Wireless World, «UMTS protocol stack », URL:

http://www.rfwireless-world.com/Tutorials/UMTS-protocol-stack.html
[9] LONG TERM EVOLUTION, «RRC CONNECTION ESTABLISHEMENT », URL:
http://lte-bullets.com/LTE%20in%20Bullets%20-%20RRC%20Establishment.pdf
[10] Frédéric Launay, Université de Poitiers, « Protocoles NAS et Protocoles AS», 15, rue de l'Hôtel Dieu -
86034 POITIERS Cedex - France, 25 janvier 2015, URL:
http://blogs.univ-poitiers.fr/f-launay/tag/non-access-stratum/
[11] MARBEN, «Free Online ASN.1 Decoder », URL:
http://www.marben-products.com/asn.1/services/decoder-asn1.html
[12] Ulf Lamping, Richard Sharpe, Ed Warnicke, «Wireshark User’s Guide For Wireshark 2.1», 2004-2014,
URL:
https://www.wireshark.org/docs/wsug_html/
[13] RTL-SDR.COM, «About RTL-SDR », URL:

62
http://www.rtl-sdr.com/about-rtl-sdr/
[14] RTL-SDR.COM, «RTL-SDR Tutorial: Analyzing GSM with Airprobe/GR-GSM and Wireshark », URL:
http://www.rtl-sdr.com/rtl-sdr-tutorial-analyzing-gsm-with-airprobe-and-wireshark/

[15] 3glteinfo, «3GPP Decoder for LTE, UMTS and GSM», URL:
http://www.3glteinfo.com/3gpp-decoder/
[16] Accuver, «XCAL-W, User Guide», Janvier 2009.

[17] Ruian Lou, Arularasan Ramasamy, and Sivakumar Viswanathan, « A Generic Encoding/Decoding
Methodology for UMTS L3 Messages based on ASN.l and ECN», Institute for Infocomm Research, 21 Heng
Mui Keng Terrace, Singapore 119613, e-mail: {10uruian.arul.siva}@i2r.a-star.edu.sg,
URL:http://ieeexplore.ieee.org/document/1404640/
[18] Prof John Larmouth, «ASN.1 Complete», Open Systems Solutions 1999, URL:
http://blogs.univ-poitiers.fr/f-launay/tag/non-access-stratum/
[19] ITU Committed to connecting the world, «Introduction to ASN.1», URL:
http://www.itu.int/en/ITU-T/asn1/Pages/introduction.aspx
[20] Abstract Syntax Notation One, «Example», URL:
https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One

[21] CSN.1.info, «CSN.1 VS ASN.1», URL:

http://csn1.info/csn1_csn_1_vs_asn_1.html
[22] ASNC, «ASN.1 Basics», URL:
http://lionet.info/asn1c/basics.html
[23] Lev Walkin, « Using the Open Source ASN.1 Compiler», March 28, 2013, URL:
http://lionet.info/asn1c/asn1c-usage.pdf vlm@lionet.info
[24] moiji-mobile, «Analyze cellular problems using Quectel modules», April 04, 2016, URL:
https://www.moiji-mobile.com/2016/09/04/quectel-uc20-ec20-qxdm/

[25] Quectel, « EC25 Mini PCIe », URL:

http://www.quectel.com/product/ec25minipcie.htm

[26] Sixfab, «make-a-ppp-internet-connection», URL:

http://sixfab.com/updated-tutorial-3-make-a-ppp-internet-connection-with-3g-4glte-shields-on-
raspberry-pi/
[27] github, « xgoldmon », URL:
https://github.com/2b-as/xgoldmon
[28] SIERRA WIRELESS, AirPrime MC7710, « Product Technical Specification & Customer Design
Guidelines », URL:
http://ec-mobile.ru/user_files/File/IRZ/MC7710_Hardware_PTS_v3.0_ENG.pdf

[29] SIERRA WIRELESS, AirPrime MC7710, « AirPrime - MC Series - Development Kit User Guide s », Jun
18, 2014, URL:

63
https://source.sierrawireless.com/resources/airprime/development_kits/airprime_mc_series_develop
ment_kit_board_quick_start_guide/

[30] SIERRA WIRELESS, AirPrime MC7710, « Linux QMI SDK Application Developer Guide », Oct 13,
2015, URL:
https://source.sierrawireless.com/resources/airprime/software/linux-qmi-sdk-application-developer-
guide-1,-d-,26/

[31] Aleksander Morgado, Lanedo, « Qualcomm Gobi devices in Linux based systems», December 10, 2013,
URL:
http://www.lanedo.com/documents/Qualcomm%20Gobi%20devices%20on%20Linux.pdf

[32] Kapetanakis Nikolaos, University of Piraeus Department of Digital Systems PMS "Techno-Economical
Management and Security of Digital Systems" « Study, analysis, implement and testing of malware mobile
station (mal-MS) using a clone Sim card, an Arduino, AT commands and Qualcomm applications (QXDM,
QPST) »,
URL: http://dione.lib.unipi.gr/xmlui/bitstream/handle/unipi/8835/Kapetanakis_Nikolaos.pdf?sequence=1

[33] Vangie Beal, « SDK - software development kit», URL:

http://www.webopedia.com/TERM/S/SDK.html

[33] Geoff Knagge, « The Universal Serial Bus :How it Works and What it Does, URL:
http://www.geoffknagge.com/uni/elec101/essay.shtml

64
Annexes
1. Trainee and contact detail

Hassan SALLOUM

Mobile : +33751055459

Email : salloum.hassan@outlook.com

Address: 92220 Chatillon, France

Education: Master recherche in Automatique robotique et informatique appliquée, Option :

système temps réel embarquée

Position in the company: internship - Computer science engineer

2. Company details:

ORANGE Garden_ Telecommunication chain providing Internet and telephony services and
portable devices.

Adresse: Orange Gardens: 40 - 48 avenue de la République 92320 Châtillon.

3. The mission entrusted to the trainee : Capturing and decoding of the mobile radio messages

4. The duration of the Internship is 6 months : 01/03/2017 – 31/08/2017

5. The Stage Master :

Mr. DUCLOS Laurent – Technical Project Coordinator ORANGE/IMT/OLN/QOP/QSI/NIS

Mobile: +33672812008

Email: Laurent.Duclos@orange.com

65