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

É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 lowvolume 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 (DLSCH): 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 HackRF 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-

gr-etcetera

git+https://github.com/gnuradio/gr-

recipes.git $

sudo

pybombs

recipes

add

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 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) GAN TCP/ GAN UDP/ GSM CCCH/ GSM SACCH/ LLC/ NAS/ SNDCP SNDCPXID

UMTS

GSM

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 binarybased 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 | 0 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); This is a random tag 123 3.14159265 2.7182818284

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 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 TDD-LTE 3G GSM/EDGE Embedded Region

B1/B3/B5/B7/B8/B20 B1/B40/B41 WCDMA B1/B5/B8 B3/B8 GNSS Optional 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 pppcreator.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, pkgconfig, 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 ] [-l] [-s] [-i ] [-v] -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+=?

Read Command

AT+?

Write Command

AT+=<…>

Execution Command

AT+

This command returns the list of parameters and value ranges set with the corresponding Write Command or by internal processes This command returns the currently set value of the parameter or parameters This command sets the user definable parameter values This command reads non0varible parameters affected by internal processes in the GSM engine

Table 4: AT command use Command AT+CPIN=0000 AT+CPWD=”SC”,”old”,”new” AT+CLCK=”SC”,0,”0000” AT&V ATI AT+COPS=? AT+CSQ ATD*99# AT+CGDCONT=1,”IP”, “access.point.name”

Description Enter PIN code Change PIN code from ‘old’ to ‘new’ Remove PIN code Status Status (Manufacturer, Model, revision, IMEI, Capabilities) List available network 0-Unknows/ 2-Current/ 3Forbidden, Longname, Shortname, Numerical-ID, “ACT” Get signal strength Answer: +CSQ: / Dial access point Defines PDP context

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 boothold (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 Pipe packet 00000002 Setup packet

Test 1

Test 2

Test 1

Test 2

Test for 30s after launching XCAL Control Transfers 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 [email protected] [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-onraspberry-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-developerguide-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 : [email protected] 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: [email protected]

65