« Comment détecter la fraude à la SIMBox au sein d'un opérateur de télécommunications ?» de manière à :

* Réduire le manque à gagner pour les opérateurs ;

* Réduire au maximum le nombre de faux positifs/ faux négatifs ;

* Réduire le cout de déploiement des techniques de détection de la fraude à la SIMBox ;

* Ouvrir une brèche dans la recherche pour la détection en temps réel de la fraude à la SIMBox.

SYNTHÈSE

Dans de cette partie il a été question pour nous présenter la problématique de notre sujet de mémoire. Il en ressort que du fait de l'explosion du marché des télécommunications, de l'existence de facteurs de la prolifération de la fraude et de son évolution vertigineuse, il en ressort que développement d'une méthode efficace pour la détection de la fraude devient une évidence. D'où le thème de notre mémoire « Déploiement et configuration d'une architecture matérielle de capture et d'analyse de la signalisation des réseaux cellulaires pour la détection des fraudes a la SIMbox. »
# CHAPITRE II : MÉTHODOLOGIE

## Partie 1 : ETAT DE L'ART

### DESCRIPTION

Malgré la dangerosité de la fraude à la SIMBox, il n'y a que très peu de recherche faite pour
favoriser le déploiement de solutions efficaces. Cette partie nous permettra de présenter les
méthodes existantes de détection de la fraude à la SIMBox, notamment les méthodes passives
et actives, de les comparer et d'expliquer les raisons du choix de la méthode que nous avons
exploré. Tout cela sur la base des informations proposées dans [28].

### PLAN :

<table><tr><td>1.</td><td>Les méthodes passives</td><td>49</td></tr><tr><td>1.1.</td><td>Analyse basée sur les CDR</td><td>49</td></tr><tr><td>1.2.</td><td>Analyse basée sur la qualité audio</td><td>49</td></tr><tr><td>1.3.</td><td>Analyse basée sur la signalisation</td><td>50</td></tr><tr><td>2.</td><td>Les méthodes actives</td><td>50</td></tr><tr><td>2.1</td><td>Test call generators (TCG)</td><td>50</td></tr><tr><td>2.1</td><td>Méthode basée sur des règles (rule-based method in Fraud Management System)</td><td>51</td></tr><tr><td>3.</td><td>Choix de la méthode utilisée</td><td>52</td></tr></table>

Mémoire de fin d'études en vue de l'obtention du Diplôme d'Ingénieur de Conception en
Télécommunications
# CHAPITRE II : MÉTHODOLOGIE

## Partie 1 : ETAT DE L'ART

### DESCRIPTION

Malgré la dangerosité de la fraude à la SIMBox, il n'y a que très peu de recherche faite pour
favoriser le déploiement de solutions efficaces. Cette partie nous permettra de présenter les
méthodes existantes de détection de la fraude à la SIMBox, notamment les méthodes passives
et actives, de les comparer et d'expliquer les raisons du choix de la méthode que nous avons
exploré. Tout cela sur la base des informations proposées dans [28].

### PLAN :

<table><tr><td>1.</td><td>Les méthodes passives</td><td>49</td></tr><tr><td>1.1.</td><td>Analyse basée sur les CDR</td><td>49</td></tr><tr><td>1.2.</td><td>Analyse basée sur la qualité audio</td><td>49</td></tr><tr><td>1.3.</td><td>Analyse basée sur la signalisation</td><td>50</td></tr><tr><td>2.</td><td>Les méthodes actives</td><td>50</td></tr><tr><td>2.1</td><td>Test call generators (TCG)</td><td>50</td></tr><tr><td>2.1</td><td>Méthode basée sur des règles (rule-based method in Fraud Management System)</td><td>51</td></tr><tr><td>3.</td><td>Choix de la méthode utilisée</td><td>52</td></tr></table>

Mémoire de fin d'études en vue de l'obtention du Diplôme d'Ingénieur de Conception en
Télécommunications
# 1. LES METHODES PASSIVES

Ce sont des méthodes qui ne nécessitent pas une action humaine permanente. Elles sont basées sur l'analyse de données de type différents.

Il en existe plusieurs parmi lesquelles :

* L'analyse basée sur les CDR ;

* L'analyse basée sur la qualité audio ;

* L'analyse basée sur la signalisation ;

## 1.1. Analyse basée sur les CDR

C'est une méthode passive qui consiste à analyser à la fois le contenu et les occurrences des CDR (Call Detail Records) qui sont des données qui répertorie l'activité dans le réseau, en termes d'appel, de SMS et d'internet. Cette méthode se base sur le Machine Learning pour faire sortir des anomalies dans ce grand jeu de données. C'est un problème de classification. Elle se fait en plusieurs étapes :

* **Préparation des données** : c'est une étape qui consiste à identifier les caractéristiques basées sur les données dans les CDR. On a :

* La fréquence d'appels

* La mobilité

* L'utilisation des services mobiles

* Propriétés des entités (les informations sur le terminal mobile)

* **Création et évaluation du modèle** : des méthodes de classification sont utilisées dont, Artificial Neural Network (ANN), Support Vector Machine (SVM), Fuzzy Logic, Random Forest. Ces modèles offrent des résultats pertinents mais leur efficacité peut être réduite par le HBS.

## 1.2. Analyse basée sur la qualité audio

Cette méthode consiste à analyser des enregistrements audios, qui révèlent un certain nombre d'informations sur le trafic. Notamment la source et le type de réseau téléphonique
# 1. LES METHODES PASSIVES

Ce sont des méthodes qui ne nécessitent pas une action humaine permanente. Elles sont basées sur l'analyse de données de type différents.

Il en existe plusieurs parmi lesquelles :

* L'analyse basée sur les CDR ;

* L'analyse basée sur la qualité audio ;

* L'analyse basée sur la signalisation ;

## 1.1. Analyse basée sur les CDR

C'est une méthode passive qui consiste à analyser à la fois le contenu et les occurrences des CDR (Call Detail Records) qui sont des données qui répertorie l'activité dans le réseau, en termes d'appel, de SMS et d'internet. Cette méthode se base sur le Machine Learning pour faire sortir des anomalies dans ce grand jeu de données. C'est un problème de classification. Elle se fait en plusieurs étapes :

* **Préparation des données** : c'est une étape qui consiste à identifier les caractéristiques basées sur les données dans les CDR. On a :

* La fréquence d'appels

* La mobilité

* L'utilisation des services mobiles

* Propriétés des entités (les informations sur le terminal mobile)

* **Création et évaluation du modèle** : des méthodes de classification sont utilisées dont, Artificial Neural Network (ANN), Support Vector Machine (SVM), Fuzzy Logic, Random Forest. Ces modèles offrent des résultats pertinents mais leur efficacité peut être réduite par le HBS.

## 1.2. Analyse basée sur la qualité audio

Cette méthode consiste à analyser des enregistrements audios, qui révèlent un certain nombre d'informations sur le trafic. Notamment la source et le type de réseau téléphonique
utilisé, à partir d'une analyse des pertes de paquets et du bruit. Cette analyse approfondie peut
permettre de dire, à partir de la dégradation de la qualité, si ce trafic vient d'un routage par la
SIMBox.

## 1.3. Analyse basée sur la signalisation

C'est une méthode récente et pas suffisamment exploitée. Elle a été suggérée en 2015
par LATRO Services dans [7] et semble très prometteuse. L'idée est d'analyser la signalisation
d'un utilisateur pour chacune de ses activités dans le réseau. A partir des protocoles connus de
la pile protocolaire LTE, on peut extraire des informations sur l'utilisateur, et rechercher une
caractéristique particulière, propre à la SIMBox. On peut, dans ce but, s'intéresser à des
evènements particuliers tels que l'attachement au réseau et ainsi bloquer une carte SIM de la
SIMBox dès sa première connexion au réseau.

## 2. LES METHODES ACTIVES

Ce sont des méthodes qui nécessitent une activité humaine permanente dans leur
déploiement. Ce sont les méthodes les plus classiques qu'utilisent les opérateurs et demandent
de grandes ressources matérielles. On peut citer :

* Test Call Generators ;

* Rule-based method in Fraud Management System (FMS)

### 2.1 Test call generators (TCG)

Les opérateurs télécoms utilisent les TCG pour consolider leurs stratégies d'assurance
des revenus. Ils fournissent des tests automatisés en exécutant des appels en direct sur le réseau
de l'opérateur pour identifier les problèmes potentiels de performance du réseau et les fuites de
revenus. Les TCG produisent des CDR indépendants qui sont comparés aux CDR des
opérateurs afin de valider l'intégrité des CDR et, en fin de compte, de découvrir les pertes de
revenus. Voici quelques services offerts par TCG :
utilisé, à partir d'une analyse des pertes de paquets et du bruit. Cette analyse approfondie peut
permettre de dire, à partir de la dégradation de la qualité, si ce trafic vient d'un routage par la
SIMBox.

## 1.3. Analyse basée sur la signalisation

C'est une méthode récente et pas suffisamment exploitée. Elle a été suggérée en 2015
par LATRO Services dans [7] et semble très prometteuse. L'idée est d'analyser la signalisation
d'un utilisateur pour chacune de ses activités dans le réseau. A partir des protocoles connus de
la pile protocolaire LTE, on peut extraire des informations sur l'utilisateur, et rechercher une
caractéristique particulière, propre à la SIMBox. On peut, dans ce but, s'intéresser à des
evènements particuliers tels que l'attachement au réseau et ainsi bloquer une carte SIM de la
SIMBox dès sa première connexion au réseau.

## 2. LES METHODES ACTIVES

Ce sont des méthodes qui nécessitent une activité humaine permanente dans leur
déploiement. Ce sont les méthodes les plus classiques qu'utilisent les opérateurs et demandent
de grandes ressources matérielles. On peut citer :

* Test Call Generators ;

* Rule-based method in Fraud Management System (FMS)

### 2.1 Test call generators (TCG)

Les opérateurs télécoms utilisent les TCG pour consolider leurs stratégies d'assurance
des revenus. Ils fournissent des tests automatisés en exécutant des appels en direct sur le réseau
de l'opérateur pour identifier les problèmes potentiels de performance du réseau et les fuites de
revenus. Les TCG produisent des CDR indépendants qui sont comparés aux CDR des
opérateurs afin de valider l'intégrité des CDR et, en fin de compte, de découvrir les pertes de
revenus. Voici quelques services offerts par TCG :
* Test en temps réel de plusieurs services d'appel et de données, par exemple voix, SMS, MMS, HTTP, télévision mobile, appels vidéo, téléchargement de contenu (jeux, sonneries, etc.).

* Réconciliation de bout en bout de la fiche d'appel (du commutateur à la facturation)

* Tests de vérification des nouveaux tarifs

* Réconciliation de la correspondance des CDR

* Validation de la tarification des appels pour la facturation d'interconnexion

* Tests de conformité réglementaire

* Tests de performance du réseau pour valider les nouveaux composants du réseau

Pour la détection de la SIMBox on réalise ses tests pour des appels internationaux et on, analyse la conformité des routes. C'est une méthode qui a peu de faux négatifs mais elle est très coûteuse à mettre en place.

## 2.1 Méthode basée sur des règles (rule-based method in Fraud Management System)

Les méthodes basées sur des règles [38] consistent à établir des règles de base pour le profilage des abonnés afin d'identifier les cartes SIM frauduleuses. Cela implique l'analyse et la surveillance des modèles d'appels (nombre d'appels sortants, ratio de destinations distinctes, sites cellulaires utilisés, rapport entre appels entrants et sortants, SMS, etc.) d'un ensemble d'abonnés par des experts à la recherche d'un comportement anormal provenant de la carte SIM d'un opérateur ou aboutissant sur celle-ci. Tout cas identifié et validé (par un appel ou une action similaire) peut alors être utilisé pour profiler et découvrir d'autres cartes SIM similaires.

Cette méthode est peu coûteuse et était très efficace pour les modèles de SIMBox n'implémentant pas la simulation du comportement humain. Par contre pour les nouveaux modèles implémentant HBS, le nombre de faux positifs devient plus élevé.
* Test en temps réel de plusieurs services d'appel et de données, par exemple voix, SMS, MMS, HTTP, télévision mobile, appels vidéo, téléchargement de contenu (jeux, sonneries, etc.).

* Réconciliation de bout en bout de la fiche d'appel (du commutateur à la facturation)

* Tests de vérification des nouveaux tarifs

* Réconciliation de la correspondance des CDR

* Validation de la tarification des appels pour la facturation d'interconnexion

* Tests de conformité réglementaire

* Tests de performance du réseau pour valider les nouveaux composants du réseau

Pour la détection de la SIMBox on réalise ses tests pour des appels internationaux et on, analyse la conformité des routes. C'est une méthode qui a peu de faux négatifs mais elle est très coûteuse à mettre en place.

## 2.1 Méthode basée sur des règles (rule-based method in Fraud Management System)

Les méthodes basées sur des règles [38] consistent à établir des règles de base pour le profilage des abonnés afin d'identifier les cartes SIM frauduleuses. Cela implique l'analyse et la surveillance des modèles d'appels (nombre d'appels sortants, ratio de destinations distinctes, sites cellulaires utilisés, rapport entre appels entrants et sortants, SMS, etc.) d'un ensemble d'abonnés par des experts à la recherche d'un comportement anormal provenant de la carte SIM d'un opérateur ou aboutissant sur celle-ci. Tout cas identifié et validé (par un appel ou une action similaire) peut alors être utilisé pour profiler et découvrir d'autres cartes SIM similaires.

Cette méthode est peu coûteuse et était très efficace pour les modèles de SIMBox n'implémentant pas la simulation du comportement humain. Par contre pour les nouveaux modèles implémentant HBS, le nombre de faux positifs devient plus élevé.
3. CHOIX DE LA METHODE UTILISEE

Au regard de toutes ces méthodes nous allons faire une étude comparative afin de mettre en évidence la pertinence de la méthode basée sur la signalisation.

<table><caption>Tableau 4: Comparaison des méthodes de détection de la fraude à la SIMBox</caption><thead><tr><td>Méthode</td><td>Avantages</td><td>Inconvénients</td><td>Contre-mesures</td></tr></thead><tbody><tr><td>TCG</td><td>Pas de faux positifs</td><td>Coûteuse</td><td><ul><li>Anti-spam</li><li>Sacrifice de cartes SIM</li></ul></td></tr><tr><td>Rule-based</td><td><ul><li>Moins coûteuse</li><li>Grande couverture</li></ul></td><td><ul><li>Monitoring constant</li><li>Grand nombre de faux positifs</li><li>Explosion du nombre de règles</li></ul></td><td>HBS</td></tr><tr><td>Signaling-based</td><td><ul><li>Très précise</li><li>Détection en temps réel</li><li>Peu coûteuse</li></ul></td><td><ul><li>Accessibilité des données</li><li>Complexité de l'analyse</li></ul></td><td></td></tr><tr><td>CDR-based</td><td><ul><li>Très efficace avec une bonne base de données</li></ul></td><td><ul><li>Dépend des données de terrain (biais)</li></ul></td><td>HBS</td></tr></tbody></table>

Mémoire de fin d'études en vue de l'obtention du Diplôme d'Ingénieur de Conception en Télécommunications
3. CHOIX DE LA METHODE UTILISEE

Au regard de toutes ces méthodes nous allons faire une étude comparative afin de mettre en évidence la pertinence de la méthode basée sur la signalisation.

<table><caption>Tableau 4: Comparaison des méthodes de détection de la fraude à la SIMBox</caption><thead><tr><td>Méthode</td><td>Avantages</td><td>Inconvénients</td><td>Contre-mesures</td></tr></thead><tbody><tr><td>TCG</td><td>Pas de faux positifs</td><td>Coûteuse</td><td><ul><li>Anti-spam</li><li>Sacrifice de cartes SIM</li></ul></td></tr><tr><td>Rule-based</td><td><ul><li>Moins coûteuse</li><li>Grande couverture</li></ul></td><td><ul><li>Monitoring constant</li><li>Grand nombre de faux positifs</li><li>Explosion du nombre de règles</li></ul></td><td>HBS</td></tr><tr><td>Signaling-based</td><td><ul><li>Très précise</li><li>Détection en temps réel</li><li>Peu coûteuse</li></ul></td><td><ul><li>Accessibilité des données</li><li>Complexité de l'analyse</li></ul></td><td></td></tr><tr><td>CDR-based</td><td><ul><li>Très efficace avec une bonne base de données</li></ul></td><td><ul><li>Dépend des données de terrain (biais)</li></ul></td><td>HBS</td></tr></tbody></table>

Mémoire de fin d'études en vue de l'obtention du Diplôme d'Ingénieur de Conception en Télécommunications
<table><tr><td></td><td><ul><li>Evolution des techniques de ML</li></ul></td><td><ul><li>Durée de détection énorme</li></ul></td><td></td></tr><tr><td>Audio quality</td><td><ul><li>Détection en temps réel</li></ul></td><td><ul><li>Augmentation des faux positifs avec la qualité de la voix sur IP (5G, 6G)</li></ul></td><td>Amélioration de la qualité du réseau IP entre équipements de la SIMBox</td></tr></table>

Ce tableau révèle que la méthode basée sur la signalisation est très efficace, peu coûteuse et à ce jour il n'existe pas encore de contre mesure du côté des fraudeurs.

## SYNTHESE

Dans cette partie il a été question pour nous de présenter d'un point de vue scientifique et technique les travaux qui ont déjà été effectués sur la détection de la fraude à la SIMBox. Sur cette base nous avons pu sélectionner une méthode que nous allons implémenter.
<table><tr><td></td><td><ul><li>Evolution des techniques de ML</li></ul></td><td><ul><li>Durée de détection énorme</li></ul></td><td></td></tr><tr><td>Audio quality</td><td><ul><li>Détection en temps réel</li></ul></td><td><ul><li>Augmentation des faux positifs avec la qualité de la voix sur IP (5G, 6G)</li></ul></td><td>Amélioration de la qualité du réseau IP entre équipements de la SIMBox</td></tr></table>

Ce tableau révèle que la méthode basée sur la signalisation est très efficace, peu coûteuse et à ce jour il n'existe pas encore de contre mesure du côté des fraudeurs.

## SYNTHESE

Dans cette partie il a été question pour nous de présenter d'un point de vue scientifique et technique les travaux qui ont déjà été effectués sur la détection de la fraude à la SIMBox. Sur cette base nous avons pu sélectionner une méthode que nous allons implémenter.
# Partie 2 : ANALYSE ET CONCEPTION

## DESCRIPTION

Dans cette partie nous ferons une analyse approfondie de la méthode basée sur la signalisation, en présentant chacun des aspects et caractéristiques sur lesquelles nous nous baserons pour mener notre expérience.

## PLAN :

<table><tr><td>1.</td><td>Hypothèse de base</td><td>55</td></tr><tr><td>2.</td><td>Synthèse des problèmes et solutions</td><td>56</td></tr><tr><td>2.1.</td><td>Difficultés liées à cette solution</td><td>56</td></tr><tr><td>2.2.</td><td>Propositions de solution</td><td>56</td></tr></table>

Mémoire de fin d'études en vue de l'obtention du Diplôme d'Ingénieur de Conception en Télécommunications
# Partie 2 : ANALYSE ET CONCEPTION

## DESCRIPTION

Dans cette partie nous ferons une analyse approfondie de la méthode basée sur la signalisation, en présentant chacun des aspects et caractéristiques sur lesquelles nous nous baserons pour mener notre expérience.

## PLAN :

<table><tr><td>1.</td><td>Hypothèse de base</td><td>55</td></tr><tr><td>2.</td><td>Synthèse des problèmes et solutions</td><td>56</td></tr><tr><td>2.1.</td><td>Difficultés liées à cette solution</td><td>56</td></tr><tr><td>2.2.</td><td>Propositions de solution</td><td>56</td></tr></table>

Mémoire de fin d'études en vue de l'obtention du Diplôme d'Ingénieur de Conception en Télécommunications
# 1. HYPOTHESE DE BASE

Pour analyser la signalisation à notre niveau, nous avons recherché des variables caractéristiques qui nous permettront de distinguer la SIMBox des terminaux réguliers. Pour retrouver de telles variables nous avons étudié la signalisation dans le cas de l'attachement au réseau. Cette signalisation est précieuse car non seulement elle ne peut être modifiée par les fraudeurs, mais aussi elle permet de détecter les fraudeurs dès leur entrée dans le réseau.

Pour ce faire nous nous sommes intéressés à la latence de communications. Comme présenté à la page 31, la SIMBank est le lieu où l'on insère physiquement les cartes SIM, mais ne communique pas avec la station de base. Elle communique les informations à la gateway via IP, qui ensuite communiquera avec la station de base. Ainsi avant toute interaction avec la station de base, il y a une communication IP entre équipements de la SIMBox et de ce fait une latence supplémentaire indépendante du réseau LTE.

<figure><img src="image_27.png" /><figcaption>Figure 20: Latences supplémentaires dans la communication de la SIMBox</figcaption></figure>

La Figure 20 nous montre que dans le cas de la SIMBox, il y a deux latences supplémentaires L1 et L2 qui s'ajoutent à L3 qui elle, est la latence normale du réseau LTE. Ainsi nous nous attendons à ce que la latence de communication entre la station de base et la SIMBox soit plus élevée que celles des terminaux réguliers. Nous avons ainsi obtenu un critère de classification.

« Notre hypothèse fondamentale réside donc dans le fait que la latence des communications IP entre équipements de la SIMBox est suffisamment grande par
# 1. HYPOTHESE DE BASE

Pour analyser la signalisation à notre niveau, nous avons recherché des variables caractéristiques qui nous permettront de distinguer la SIMBox des terminaux réguliers. Pour retrouver de telles variables nous avons étudié la signalisation dans le cas de l'attachement au réseau. Cette signalisation est précieuse car non seulement elle ne peut être modifiée par les fraudeurs, mais aussi elle permet de détecter les fraudeurs dès leur entrée dans le réseau.

Pour ce faire nous nous sommes intéressés à la latence de communications. Comme présenté à la page 31, la SIMBank est le lieu où l'on insère physiquement les cartes SIM, mais ne communique pas avec la station de base. Elle communique les informations à la gateway via IP, qui ensuite communiquera avec la station de base. Ainsi avant toute interaction avec la station de base, il y a une communication IP entre équipements de la SIMBox et de ce fait une latence supplémentaire indépendante du réseau LTE.

<figure><img src="image_29.png" /><figcaption>Figure 20: Latences supplémentaires dans la communication de la SIMBox</figcaption></figure>

La Figure 20 nous montre que dans le cas de la SIMBox, il y a deux latences supplémentaires L1 et L2 qui s'ajoutent à L3 qui elle, est la latence normale du réseau LTE. Ainsi nous nous attendons à ce que la latence de communication entre la station de base et la SIMBox soit plus élevée que celles des terminaux réguliers. Nous avons ainsi obtenu un critère de classification.

« Notre hypothèse fondamentale réside donc dans le fait que la latence des communications IP entre équipements de la SIMBox est suffisamment grande par
rapport à celle des terminaux réguliers pour faire la distinction. Ainsi il est possible
détecter un utilisateur frauduleux localement en analysant la signalisation d'une station
de base, et plus encore le faire dès son entrée dans le réseau via la signalisation de la
procédure d'attachement. ».

## 2. SYNTHESE DES PROBLEMES ET SOLUTIONS

### 2.1. Difficultés liées à cette solution

Comme précédemment mentionné l'analyse de la signalisation pour la détection de la SIMBox est une solution peu explorée. Nous utilisons une méthode jamais encore utilisée et de ce fait des obstacles notables se sont présentés. On distingue notamment :

* La rareté d'articles scientifiques traitant du sujet ;

* L'accès difficile aux données de signalisation auprès d'opérateurs en production, sans lesquelles aucune analyse n'est possible ;

* La nécessité de reproduire l'écosystème de la fraude pour des tests. Et donc de ce fait des autorisations auprès d'opérateurs ;

* Les coûts de déploiement de station de base ;

* Les coûts très élevés d'acquisition de fréquences, même pour es raisons expérimentales par SDR.

### 2.2. Propositions de solution

La plupart des inconvénients de la méthode que nous souhaitons implémenter sont d'ordre matériel. Le Tableau 5 suivant présente les solutions que nous avons mis en place à chaque difficulté précédemment mentionnée.

<table><caption>Tableau 5: Tableau problème – solution de la méthode de détection à développer</caption><thead><tr><td>Problème</td><td>Solution</td></tr></thead></table>

Mémoire de fin d'études en vue de l'obtention du Diplôme d'Ingénieur de Conception en Télécommunications
rapport à celle des terminaux réguliers pour faire la distinction. Ainsi il est possible
détecter un utilisateur frauduleux localement en analysant la signalisation d'une station
de base, et plus encore le faire dès son entrée dans le réseau via la signalisation de la
procédure d'attachement. ».

## 2. SYNTHESE DES PROBLEMES ET SOLUTIONS

### 2.1. Difficultés liées à cette solution

Comme précédemment mentionné l'analyse de la signalisation pour la détection de la SIMBox est une solution peu explorée. Nous utilisons une méthode jamais encore utilisée et de ce fait des obstacles notables se sont présentés. On distingue notamment :

* La rareté d'articles scientifiques traitant du sujet ;

* L'accès difficile aux données de signalisation auprès d'opérateurs en production, sans lesquelles aucune analyse n'est possible ;

* La nécessité de reproduire l'écosystème de la fraude pour des tests. Et donc de ce fait des autorisations auprès d'opérateurs ;

* Les coûts de déploiement de station de base ;

* Les coûts très élevés d'acquisition de fréquences, même pour es raisons expérimentales par SDR.

### 2.2. Propositions de solution

La plupart des inconvénients de la méthode que nous souhaitons implémenter sont d'ordre matériel. Le Tableau 5 suivant présente les solutions que nous avons mis en place à chaque difficulté précédemment mentionnée.

<table><caption>Tableau 5: Tableau problème – solution de la méthode de détection à développer</caption><thead><tr><td>Problème</td><td>Solution</td></tr></thead></table>

Mémoire de fin d'études en vue de l'obtention du Diplôme d'Ingénieur de Conception en Télécommunications
<table><thead><tr><th></th><th></th></tr></thead><tbody><tr><td>Rareté d'articles sur le sujet de la détection basée sur la signalisation</td><td>Etude des normes de réseaux cellulaires</td></tr><tr><td>Accès difficile aux données de signalisation</td><td>Déploiement d'un opérateur privé, de manière à ne pas perturber de réseau en production, et de gagner du temps dans les procédures administratives.</td></tr><tr><td>Nécessité de reproduire l'écosystème de la fraude</td><td>Déploiement de la SIMBox (d'un fabriquant quelconque, HyberTone dans notre cas) dans un opérateur privé.</td></tr><tr><td>Coûts de déploiement de station de base</td><td>Utilisation de la technologie SDR, qui permet de déployer une station de base via une carte électronique à moindre coût.</td></tr><tr><td>Règlementation sur les fréquences</td><td>Expérimentation dans une cage de Faraday, pour empêcher les interférences sur les bandes de fréquences d'autres opérateurs.</td></tr></tbody></table>

## SYNTHÈSE

Dans cette partie, il a été question pour nous de présenter les méthodes de détection précédentes, d'en ressortir les points forts et les points faibles, de manière illustrer les raisons de notre choix d'explorer la méthode de détection basée sur la signalisation. Il en ressort que la méthode de signalisation est plus intéressante du fait de sa grande précision, de son coût de déploiement peu élevé et du fait qu'il n'existe encore aucune contre-mesure du côté des fraudeurs. Ensuite nous avons présenté notre démarche dans l'expérimentation de notre solution.
<table><thead><tr><th></th><th></th></tr></thead><tbody><tr><td>Rareté d'articles sur le sujet de la détection basée sur la signalisation</td><td>Etude des normes de réseaux cellulaires</td></tr><tr><td>Accès difficile aux données de signalisation</td><td>Déploiement d'un opérateur privé, de manière à ne pas perturber de réseau en production, et de gagner du temps dans les procédures administratives.</td></tr><tr><td>Nécessité de reproduire l'écosystème de la fraude</td><td>Déploiement de la SIMBox (d'un fabriquant quelconque, HyberTone dans notre cas) dans un opérateur privé.</td></tr><tr><td>Coûts de déploiement de station de base</td><td>Utilisation de la technologie SDR, qui permet de déployer une station de base via une carte électronique à moindre coût.</td></tr><tr><td>Règlementation sur les fréquences</td><td>Expérimentation dans une cage de Faraday, pour empêcher les interférences sur les bandes de fréquences d'autres opérateurs.</td></tr></tbody></table>

## SYNTHÈSE

Dans cette partie, il a été question pour nous de présenter les méthodes de détection précédentes, d'en ressortir les points forts et les points faibles, de manière illustrer les raisons de notre choix d'explorer la méthode de détection basée sur la signalisation. Il en ressort que la méthode de signalisation est plus intéressante du fait de sa grande précision, de son coût de déploiement peu élevé et du fait qu'il n'existe encore aucune contre-mesure du côté des fraudeurs. Ensuite nous avons présenté notre démarche dans l'expérimentation de notre solution.
# Partie 3 : MODÉLISATION

## DESCRIPTION

Dans cette partie nous parlerons des différentes architectures déployées pour la réalisation de notre expérience. Nous présentons, ensuite l'analyse des résultats de cette dernière.

## PLAN :

<table><tr><td>1.</td><td>Architectures de réseau</td><td>59</td></tr><tr><td>1.1.</td><td>Architecture avec gateway seule</td><td>59</td></tr><tr><td>1.2.</td><td>Architecture complète de SIMBox connectée en réseau local.</td><td>60</td></tr><tr><td>1.3.</td><td>Architecture complète de SIMBox connectée via internet.</td><td>60</td></tr><tr><td>2.</td><td>Conditions expérimentales</td><td>61</td></tr><tr><td>3.</td><td>Calcul de la latence de la procédure d'attachement</td><td>62</td></tr><tr><td>3.1.</td><td>La procédure d'attachement au réseau LTE</td><td>62</td></tr><tr><td>3.2.</td><td>Méthode de calcul de la latence.</td><td>65</td></tr><tr><td>4.</td><td>Processus de collecte des données</td><td>66</td></tr><tr><td>5.</td><td>Matériel et logiciels utilisés.</td><td>68</td></tr><tr><td>5.1.</td><td>Matériel</td><td>68</td></tr><tr><td>5.2.</td><td>Logiciel</td><td>69</td></tr></table>
# Partie 3 : MODÉLISATION

## DESCRIPTION

Dans cette partie nous parlerons des différentes architectures déployées pour la réalisation de notre expérience. Nous présentons, ensuite l'analyse des résultats de cette dernière.

## PLAN :

<table><tr><td>1.</td><td>Architectures de réseau</td><td>59</td></tr><tr><td>1.1.</td><td>Architecture avec gateway seule</td><td>59</td></tr><tr><td>1.2.</td><td>Architecture complète de SIMBox connectée en réseau local.</td><td>60</td></tr><tr><td>1.3.</td><td>Architecture complète de SIMBox connectée via internet.</td><td>60</td></tr><tr><td>2.</td><td>Conditions expérimentales</td><td>61</td></tr><tr><td>3.</td><td>Calcul de la latence de la procédure d'attachement</td><td>62</td></tr><tr><td>3.1.</td><td>La procédure d'attachement au réseau LTE</td><td>62</td></tr><tr><td>3.2.</td><td>Méthode de calcul de la latence.</td><td>65</td></tr><tr><td>4.</td><td>Processus de collecte des données.</td><td>66</td></tr><tr><td>5.</td><td>Matériel et logiciels utilisés.</td><td>68</td></tr><tr><td>5.1.</td><td>Matériel</td><td>68</td></tr><tr><td>5.2.</td><td>Logiciel</td><td>69</td></tr></table>
# 1. ARCHITECTURES DE RESEAU

Dans le cadre de notre projet de fin d'études nous devons déployer et configurer une
architecture matérielle qui va nous permettre de détecter la SIMBox parmi les utilisateurs
normaux. Dans cette phase du travail, nous allons monter une architecture qui nous permettra
d'obtenir de la signalisation autant de SIMBox que d'utilisateurs réguliers. Nous avons trois
architectures principales à tester pour comparer les latences dans chacun des cas.

* Architecture avec une gateway seule ;

* Architecture complète de SIMBox, connectée en réseau local ;

* Architecture complète de SIMBox, connectée via internet ;

## 1.1. Architecture avec gateway seule

C'est le cas élémentaire de fraude à la SIMBox, dans ce cas-là il n'y a pas de
communication IP entre équipements. La carte SIM est directement connectée à la gateway et
communique directement avec la station de base. Ainsi à priori elle est similaire à un téléphone
normal.

<figure><img src="image_28.png" /><figcaption>Figure 21: Architecture de SIMBox avec une gateway seule</figcaption></figure>
# 1. ARCHITECTURES DE RESEAU

Dans le cadre de notre projet de fin d'études nous devons déployer et configurer une
architecture matérielle qui va nous permettre de détecter la SIMBox parmi les utilisateurs
normaux. Dans cette phase du travail, nous allons monter une architecture qui nous permettra
d'obtenir de la signalisation autant de SIMBox que d'utilisateurs réguliers. Nous avons trois
architectures principales à tester pour comparer les latences dans chacun des cas.

* Architecture avec une gateway seule ;

* Architecture complète de SIMBox, connectée en réseau local ;

* Architecture complète de SIMBox, connectée via internet ;

## 1.1. Architecture avec gateway seule

C'est le cas élémentaire de fraude à la SIMBox, dans ce cas-là il n'y a pas de
communication IP entre équipements. La carte SIM est directement connectée à la gateway et
communique directement avec la station de base. Ainsi à priori elle est similaire à un téléphone
normal.

<figure><img src="image_30.png" /><figcaption>Figure 21: Architecture de SIMBox avec une gateway seule</figcaption></figure>
## 1.2. Architecture complète de SIMBox connectée en réseau local.

Dans ce cas, nous déployons la SIMBox avec tous ses composants, mais connectés en local de manière à réduire au maximum la latence au niveau IP. Nous avons inséré une carte SIM dans la SIMBank, elle-même placée dans la même salle que la Gateway. Ainsi nous nous sommes assurés de créer une seule liaison « carte SIM - canal GSM » (voice channel) que nous avons configuré.

<figure><img src="image_29.png" /><figcaption>Figure 22: Architecture de SIMBox complète connectée en réseau local</figcaption></figure>

## 1.3. Architecture complète de SIMBox connectée via internet.

Dans ce cas-ci nous voulons simuler le comportement de la SIMBox de manière plus réaliste en connectant les équipements sur deux sites différents en utilisant internet. Nous avons déployé la topologie dans le but de se mettre dans des conditions réalistes, pour se rapprocher au maximum. Pour que cette topologie puisse fonctionner, il est nécessaire d'activer le *port forwarding* sur le routeur derrière lequel se trouve le SIM Server, afin de rediriger vers lui tout flux en direction des ports concernés (TCP 56012 et UDP 56011 par défaut).
## 1.2. Architecture complète de SIMBox connectée en réseau local.

Dans ce cas, nous déployons la SIMBox avec tous ses composants, mais connectés en local de manière à réduire au maximum la latence au niveau IP. Nous avons inséré une carte SIM dans la SIMBank, elle-même placée dans la même salle que la Gateway. Ainsi nous nous sommes assurés de créer une seule liaison « carte SIM - canal GSM » (voice channel) que nous avons configuré.

<figure><img src="image_31.png" /><figcaption>Figure 22: Architecture de SIMBox complète connectée en réseau local</figcaption></figure>

## 1.3. Architecture complète de SIMBox connectée via internet.

Dans ce cas-ci nous voulons simuler le comportement de la SIMBox de manière plus réaliste en connectant les équipements sur deux sites différents en utilisant internet. Nous avons déployé la topologie dans le but de se mettre dans des conditions réalistes, pour se rapprocher au maximum. Pour que cette topologie puisse fonctionner, il est nécessaire d'activer le *port forwarding* sur le routeur derrière lequel se trouve le SIM Server, afin de rediriger vers lui tout flux en direction des ports concernés (TCP 56012 et UDP 56011 par défaut).
<figure><img src="image_30.png" /><figcaption>Figure 23: Architecture de SIMBox complète connectée via internet</figcaption></figure>

## 2. CONDITIONS EXPERIMENTALES

Pour réaliser notre simulation et collecter des traces d'interactions entre station de base et les terminaux, nous nous sommes placés dans les conditions suivantes :

* Toute expérience doit être faite dans la cage de faraday (Figure 24)

* Par rapport à la station de base, tous les équipements communiquant sur la voie radio étaient à la même position.

* La station de base et les terminaux sont en visibilité directe

* Atténuation négligeable

* Paramètres de la station de base :
<figure><img src="image_32.png" /><figcaption>Figure 23: Architecture de SIMBox complète connectée via internet</figcaption></figure>

## 2. CONDITIONS EXPERIMENTALES

Pour réaliser notre simulation et collecter des traces d'interactions entre station de base et les terminaux, nous nous sommes placés dans les conditions suivantes :

* Toute expérience doit être faite dans la cage de faraday (Figure 24)

* Par rapport à la station de base, tous les équipements communiquant sur la voie radio étaient à la même position.

* La station de base et les terminaux sont en visibilité directe

* Atténuation négligeable

* Paramètres de la station de base :
o Fréquence: 2680 MHz (UL) and 2560 MHz (DL)

o Mode: FDD

* Variations du débit de l'interface Ethernet du SIM server (10 Mbps, 100 Mbps, 1000 Mbps) à l'aide du package linux **ethtool** ;

* Mesure du débit à l'aide du package linux **speedtest** ;

* Capture de paquets IP à l'aide de **Wireshark** activé sur l'interface Ethernet du SIM server.

<figure><img src="image_31.png" /><figcaption>Figure 24: Images de cage de faraday en extérieur et à l'intérieur [40]</figcaption></figure>

3. CALCUL DE LA LATENCE DE LA
PROCEDURE D'ATTACHEMENT

3.1. La procédure d'attachement au réseau LTE

Dans cette partie nous nous intéressons à la procédure d'attachement qui peut nous permettre, conformément a l'hypothèse de départ de détecter la SIMBox dès son entrée dans le réseau et avant la fraude. Afin de pouvoir calculer la latence, nous avons observé le flux des messages de signalisation échangés entre équipements pendant ladite procédure. La procédure est résumée dans la Figure 25.
o Fréquence: 2680 MHz (UL) and 2560 MHz (DL)

o Mode: FDD

* Variations du débit de l'interface Ethernet du SIM server (10 Mbps, 100 Mbps, 1000 Mbps) à l'aide du package linux **ethtool** ;

* Mesure du débit à l'aide du package linux **speedtest** ;

* Capture de paquets IP à l'aide de **Wireshark** activé sur l'interface Ethernet du SIM server.

<figure><img src="image_33.png" /><figcaption>Figure 24: Images de cage de faraday en extérieur et à l'intérieur [40]</figcaption></figure>

3. CALCUL DE LA LATENCE DE LA
PROCEDURE D'ATTACHEMENT

3.1. La procédure d'attachement au réseau LTE

Dans cette partie nous nous intéressons à la procédure d'attachement qui peut nous permettre, conformément a l'hypothèse de départ de détecter la SIMBox dès son entrée dans le réseau et avant la fraude. Afin de pouvoir calculer la latence, nous avons observé le flux des messages de signalisation échangés entre équipements pendant ladite procédure. La procédure est résumée dans la Figure 25.
<figure><img src="image_32.png" /><figcaption>Figure 25 : Attachement au réseau EPS [13]</figcaption></figure>

Cette procédure correspond à un attachement au réseau EPS qui conduira à la création d'un default bearer permanent correspondant à une connectivité IP permanente à un réseau IPv4 ou IPv6 [13].

1. L'UE initie la procédure d'attachement en émettant une requête **Attach Request** à l'eNodeB. Cette requête contient son GUTI et l'identité de l'opérateur auquel l'UE souhaite se rattacher.

2. Le MME obtient auprès du HSS disposant du profil de l'UE, des quintuplets d'authentification à l'aide de la requête **Send Authentication Info**.
<figure><img src="image_34.png" /><figcaption>Figure 25 : Attachement au réseau EPS [13]</figcaption></figure>

Cette procédure correspond à un attachement au réseau EPS qui conduira à la création d'un default bearer permanent correspondant à une connectivité IP permanente à un réseau IPv4 ou IPv6 [13].

1. L'UE initie la procédure d'attachement en émettant une requête **Attach Request** à l'eNodeB. Cette requête contient son GUTI et l'identité de l'opérateur auquel l'UE souhaite se rattacher.

2. Le MME obtient auprès du HSS disposant du profil de l'UE, des quintuplets d'authentification à l'aide de la requête **Send Authentication Info**.
3. Le MME soumet une valeur aléatoire à l'UE et escompte une réponse de l'UE contenant un résultat d'authentification égal à celui fourni par le HSS. L'UE retourne la réponse au MME.

4. Le MME demande à l'UE de lui fournir son IMEI.

5. L'EIR, interrogé par le MME indique dans le message de retour si le terminal fait ou ne fait pas partie de la liste des équipements interdits (black list).

6. Le MME délivre un message **Update Location** (adresse MME sous forme de hostname, IMSI) au HSS.

7. Le HSS émet un message **Insert Subscriber Data** (IMSI, données de souscription EPS) au nouveau MME. Le nouveau MME retourne une **réponse Insert Subscriber Data Ack** (IMSI) au HSS.

8. Le HSS acquitte la mise à jour de localisation par une réponse **Update Location Ack** au MME. En cas de rejet de la procédure de mise à jour de localisation, le MME rejette la demande d'attachement de l'UE.

9. Le MME sélectionne un S-GW et assigne une valeur au paramètre EPS Bearer Identity (BI) pour le bearer par défaut associé à cet UE. Puis, il émet une requête **Create Session Request** (pour la création du default bearer) au S-GW sélectionné.

10. Le S-GW crée une nouvelle entrée dans sa table d'EPS bearer et émet à son tour une requête **Create Session Request** au P-GW.

11. Le P-GW interagit avec le PCRF afin d'obtenir les règles de taxation permettant de différencier les flux de service qui transiteront par le default bearer et ainsi différencier la taxation de ces flux.

12. Le P-GW retourne une réponse **Create Session Response** au S-GW contenant l'adresse IP allouée à l'UE.

13. Le S-GW retourne une réponse **Create Session Response** au MME.

14. Le MME émet un message **Initial Context Setup Request**, afin de demander à l'eNodeB de créer un bearer d'accès entre l'UE et le S-GW.

15. L'eNodeB émet un message **RRC Connection Reconfiguration request** incluant l'identité du bearer d'accès et le message **Attach Accept** contenant le GUTI assigné à l'UE par le MME.
3. Le MME soumet une valeur aléatoire à l'UE et escompte une réponse de l'UE contenant un résultat d'authentification égal à celui fourni par le HSS. L'UE retourne la réponse au MME.

4. Le MME demande à l'UE de lui fournir son IMEI.

5. L'EIR, interrogé par le MME indique dans le message de retour si le terminal fait ou ne fait pas partie de la liste des équipements interdits (black list).

6. Le MME délivre un message **Update Location** (adresse MME sous forme de hostname, IMSI) au HSS.

7. Le HSS émet un message **Insert Subscriber Data** (IMSI, données de souscription EPS) au nouveau MME. Le nouveau MME retourne une **réponse Insert Subscriber Data Ack** (IMSI) au HSS.

8. Le HSS acquitte la mise à jour de localisation par une réponse **Update Location Ack** au MME. En cas de rejet de la procédure de mise à jour de localisation, le MME rejette la demande d'attachement de l'UE.

9. Le MME sélectionne un S-GW et assigne une valeur au paramètre EPS Bearer Identity (BI) pour le bearer par défaut associé à cet UE. Puis, il émet une requête **Create Session Request** (pour la création du default bearer) au S-GW sélectionné.

10. Le S-GW crée une nouvelle entrée dans sa table d'EPS bearer et émet à son tour une requête **Create Session Request** au P-GW.

11. Le P-GW interagit avec le PCRF afin d'obtenir les règles de taxation permettant de différencier les flux de service qui transiteront par le default bearer et ainsi différencier la taxation de ces flux.

12. Le P-GW retourne une réponse **Create Session Response** au S-GW contenant l'adresse IP allouée à l'UE.

13. Le S-GW retourne une réponse **Create Session Response** au MME.

14. Le MME émet un message **Initial Context Setup Request**, afin de demander à l'eNodeB de créer un bearer d'accès entre l'UE et le S-GW.

15. L'eNodeB émet un message **RRC Connection Reconfiguration request** incluant l'identité du bearer d'accès et le message **Attach Accept** contenant le GUTI assigné à l'UE par le MME.
16. L'UE retourne une réponse **RRC Connection Reconfiguration Complete** à l'eNodeB incluant le message **EMM Attach Complete**.

17. L'eNodeB retourne le message **Initial Context Response** au MME. L'UE peut à partir de ce moment émettre des paquets IP dans le sens montant vers l'eNodeB qui les routera sur le tunnel GTP-U au S-GW qui à son tour les relayera aussi sur un tunnel GTP-U au P-GW.

18. A la réception du message **Initial Context Response** et de l'**Attach Complete**, le MME émet une requête **Modify Bearer Request** au S-GW.

19. Le S-GW l'acquitte en retournant une réponse **Modify Bearer Response** (Identité du bearer EPS) au MME. Le S-GW est dès à présent prêt à relayer les paquets IP, qu'il a pu mettre temporairement en mémoire tampon, dans le sens descendant à l'UE à travers l'eNodeB.

## 3.2. Méthode de calcul de la latence

Dans cette partie nous présentons la méthode utilisée pour calculer la latence de la procédure d'attachement au réseau 4G. Nous partons du principe que nous nous intéressons uniquement aux évènements qui font intervenir la station de base. La Figure 26 nous montre la procédure d'attachement simplifiée, avec uniquement les messages envoyés et reçus par la station de base. Ainsi la latence pour une étape i est donnée par :

$$L_i = T_i - T_{i-1} \quad (1)$$

* $L_i$: la latence pour l'étape i (en ms), avec $i>0$ et $T_0 = 0$ ms

* $T_i$: le temps d'arrivée ou d'envoi du message i (en ms)

* $T_{i-1}$: le temps d'arrivée ou d'envoi du message précédent le message i (en ms)

La latence totale de l'attachement pour un utilisateur est donc ainsi donnée par :
16. L'UE retourne une réponse **RRC Connection Reconfiguration Complete** à l'eNodeB incluant le message **EMM Attach Complete**.

17. L'eNodeB retourne le message **Initial Context Response** au MME. L'UE peut à partir de ce moment émettre des paquets IP dans le sens montant vers l'eNodeB qui les routera sur le tunnel GTP-U au S-GW qui à son tour les relayera aussi sur un tunnel GTP-U au P-GW.

18. A la réception du message **Initial Context Response** et de l'**Attach Complete**, le MME émet une requête **Modify Bearer Request** au S-GW.

19. Le S-GW l'acquitte en retournant une réponse **Modify Bearer Response** (Identité du bearer EPS) au MME. Le S-GW est dès à présent prêt à relayer les paquets IP, qu'il a pu mettre temporairement en mémoire tampon, dans le sens descendant à l'UE à travers l'eNodeB.

## 3.2. Méthode de calcul de la latence

Dans cette partie nous présentons la méthode utilisée pour calculer la latence de la procédure d'attachement au réseau 4G. Nous partons du principe que nous nous intéressons uniquement aux évènements qui font intervenir la station de base. La Figure 26 nous montre la procédure d'attachement simplifiée, avec uniquement les messages envoyés et reçus par la station de base. Ainsi la latence pour une étape i est donnée par :

$$L_i = T_i - T_{i-1} \quad (1)$$

* $L_i$: la latence pour l'étape i (en ms), avec $i>0$ et $T_0 = 0$ ms

* $T_i$: le temps d'arrivée ou d'envoi du message i (en ms)

* $T_{i-1}$: le temps d'arrivée ou d'envoi du message précédent le message i (en ms)

La latence totale de l'attachement pour un utilisateur est donc ainsi donnée par :
$$L = \sum_{i=1}^{i=14} L_i = \sum_{i=1}^{i=14} T_i - T_{i-1} \quad (2)$$

Il revient donc d'appliquer cette méthode de calcul à nos traces issues de la station de base, chose que nous avons implémenté dans nos scripts.

<figure><img src="image_33.png" /><figcaption>Figure 26: Procédure d'attachement de l'UE au réseau 4G (du point de vue de la station de base)</figcaption></figure>

## 4. PROCESSUS DE COLLECTE DES DONNEES

Pour vérifier notre hypothèse, nous devons analyser la journalisation au niveau de la station de base pour pouvoir mesurer la latence de communications sur la base de la méthode montrée dans la partie précédente. Les fichiers de journalisation de la station de base
$$L = \sum_{i=1}^{i=14} L_i = \sum_{i=1}^{i=14} T_i - T_{i-1} \quad (2)$$

Il revient donc d'appliquer cette méthode de calcul à nos traces issues de la station de base, chose que nous avons implémenté dans nos scripts.

<figure><img src="image_35.png" /><figcaption>Figure 26: Procédure d'attachement de l'UE au réseau 4G (du point de vue de la station de base)</figcaption></figure>

## 4. PROCESSUS DE COLLECTE DES DONNEES

Pour vérifier notre hypothèse, nous devons analyser la journalisation au niveau de la station de base pour pouvoir mesurer la latence de communications sur la base de la méthode montrée dans la partie précédente. Les fichiers de journalisation de la station de base
comprennent énormément d'informations. Il faut avoir une bonne visibilité et compréhension
de la signalisation pour pouvoir extraire la latence. Pour ce faire nous avons choisi d'étudier
l'attachement au réseau pour plusieurs situations de la SIMBox et pour des terminaux
ordinaires.

Les tests que nous avons réalisés sont les suivants :

1. Connexion de téléphones (deux différents) à une station de base 4G ;

2. Connexion d'une Gateway seule à une station de base 4G ;

3. Connexion de la gateway, SIMBank et SIM server dans les situations suivantes :

a. En local pour des débits différents (10 Mbps, 100 Mbps, 1000 Mbps)

b. En local en utilisant UDP (débit à 100 Mbps)

c. En local en utilisant le format de données de cartes SIM « short command »
(débit à 100 Mbps, TCP et UDP)

d. Connexion à internet en utilisant TCP à un débit de 100 Mbps pour des sites distants de 19 km.

Au bout de ces expériences nous avons obtenu un fichier de journalisation de l'activité de
l'eNode B. A partir duquel nous allons extraire les latences à l'aide de scripts codés sur python.

<figure><img src="image_34.png" /><figcaption>Figure 27: Processus de collecte et d'analyse des données.</figcaption></figure>

Une fois que l'on a des fichiers csv contenant les valeurs de la latence pour chaque message envoyé pour chaque cas (les Lᵢ) on peut aisément, mettre le tout ensemble pour faire des comparaisons.
comprennent énormément d'informations. Il faut avoir une bonne visibilité et compréhension
de la signalisation pour pouvoir extraire la latence. Pour ce faire nous avons choisi d'étudier
l'attachement au réseau pour plusieurs situations de la SIMBox et pour des terminaux
ordinaires.

Les tests que nous avons réalisés sont les suivants :

1. Connexion de téléphones (deux différents) à une station de base 4G ;

2. Connexion d'une Gateway seule à une station de base 4G ;

3. Connexion de la gateway, SIMBank et SIM server dans les situations suivantes :

a. En local pour des débits différents (10 Mbps, 100 Mbps, 1000 Mbps)

b. En local en utilisant UDP (débit à 100 Mbps)

c. En local en utilisant le format de données de cartes SIM « short command »
(débit à 100 Mbps, TCP et UDP)

d. Connexion à internet en utilisant TCP à un débit de 100 Mbps pour des sites distants de 19 km.

Au bout de ces expériences nous avons obtenu un fichier de journalisation de l'activité de l'eNode B. A partir duquel nous allons extraire les latences à l'aide de scripts codés sur python.

<figure><img src="image_36.png" /><figcaption>Figure 27: Processus de collecte et d'analyse des données.</figcaption></figure>

Une fois que l'on a des fichiers csv contenant les valeurs de la latence pour chaque message envoyé pour chaque cas (les Lᵢ) on peut aisément, mettre le tout ensemble pour faire des comparaisons.
# 5. MATERIEL ET LOGICIELS UTILISES

## 5.1. Matériel

Le matériel nécessaire pour reproduire l'expérience est donné dans le Tableau 6. La plupart de ces appareils sont

<table><caption>Tableau 6: Matériel requis pour réaliser l'expérience</caption><thead><tr><td>Fonction</td><td>Modèle utilisé</td></tr></thead><tbody><tr><td>SIMBank</td><td>• HyberTone SMB32 Remote SIMBank</td></tr><tr><td>Gateway</td><td>• HyberTone GoIPx8</td></tr><tr><td>SIM Server</td><td>• Ubuntu Server 16.04 virtual machine</td></tr><tr><td>PC hôte</td><td>• DELL G7588<br>• Intel(R) Core (TM) i7-8750H CPU @ 2.20GHz (12 CPUs), ~2.2GHz<br>• 16 GB RAM</td></tr><tr><td>Station de base</td><td>• Amarisoft callbox series</td></tr><tr><td>Cœur de réseau</td><td>• Cœur de réseau d'opérateur mobile avec tous les équipements associés</td></tr><tr><td>Téléphones</td><td>• Xiaomi Redmi Note 9<br>• Huawei Mate 8</td></tr><tr><td>Cartes SIM programmables</td><td>• SysmoSIM-SJS1 de Sysmocom</td></tr></tbody></table>

Mémoire de fin d'études en vue de l'obtention du Diplôme d'Ingénieur de Conception en Télécommunications
# 5. MATERIEL ET LOGICIELS UTILISES

## 5.1. Matériel

Le matériel nécessaire pour reproduire l'expérience est donné dans le Tableau 6. La plupart de ces appareils sont

<table><caption>Tableau 6: Matériel requis pour réaliser l'expérience</caption><thead><tr><td>Fonction</td><td>Modèle utilisé</td></tr></thead><tbody><tr><td>SIMBank</td><td>• HyberTone SMB32 Remote SIMBank</td></tr><tr><td>Gateway</td><td>• HyberTone GoIPx8</td></tr><tr><td>SIM Server</td><td>• Ubuntu Server 16.04 virtual machine</td></tr><tr><td>PC hôte</td><td>• DELL G7588<br>• Intel(R) Core (TM) i7-8750H CPU @ 2.20GHz (12 CPUs), ~2.2GHz<br>• 16 GB RAM</td></tr><tr><td>Station de base</td><td>• Amarisoft callbox series</td></tr><tr><td>Cœur de réseau</td><td>• Cœur de réseau d'opérateur mobile avec tous les équipements associés</td></tr><tr><td>Téléphones</td><td>• Xiaomi Redmi Note 9<br>• Huawei Mate 8</td></tr><tr><td>Cartes SIM programmables</td><td>• SysmoSIM-SJS1 de Sysmocom</td></tr></tbody></table>

Mémoire de fin d'études en vue de l'obtention du Diplôme d'Ingénieur de Conception en Télécommunications
## 5.2. Logiciel

### 5.2.1. Ubuntu

Ubuntu est un système d'exploitation GNU/LINUX basé sur
la distribution Linux Debian. Il est développé, maintenu et
commercialisé pour les ordinateurs individuels par la société
Canonical.

Nous avons utilisé la version d'Ubuntu Server 16.04 pour notre SIM
Server et 18.04 pour le PC hôte.

<figure><img src="image_35.png" /><figcaption>Figure 28: Logo Ubuntu.</figcaption></figure>

### 5.2.2. AMARI Callbox

AMARI Callbox est la solution idéale pour tester les
appareils 5G NSA et SA, LTE, LTE-M et NB-IoT. Elle agit comme
un eNB et un EPC conformes à la norme 3GPP, ce qui permet de
réaliser des tests fonctionnels et de performance. La Callbox est
alimentée par une suite logicielle de qualité pour le déploiement.

<figure><img src="image_36.png" /><figcaption>Figure 29: Logo Amarisoft.</figcaption></figure>

### 5.2.3. Wireshark

Wireshark est l'analyseur de protocole réseau le plus utilisé et le
plus utilisé au monde. Il vous permet de voir ce qui se passe sur votre
réseau à un niveau microscopique et constitue la norme de facto (et
souvent de jure) dans de nombreuses entreprises.

<figure><img src="image_37.png" /><figcaption>Figure 30: Logo Wireshark.</figcaption></figure>
## 5.2. Logiciel

### 5.2.1. Ubuntu

Ubuntu est un système d'exploitation GNU/LINUX basé sur
la distribution Linux Debian. Il est développé, maintenu et
commercialisé pour les ordinateurs individuels par la société
Canonical.

Nous avons utilisé la version d'Ubuntu Server 16.04 pour notre SIM
Server et 18.04 pour le PC hôte.

<figure><img src="image_37.png" /><figcaption>Figure 28: Logo Ubuntu.</figcaption></figure>

### 5.2.2. AMARI Callbox

AMARI Callbox est la solution idéale pour tester les
appareils 5G NSA et SA, LTE, LTE-M et NB-IoT. Elle agit comme
un eNB et un EPC conformes à la norme 3GPP, ce qui permet de
réaliser des tests fonctionnels et de performance. La Callbox est
alimentée par une suite logicielle de qualité pour le déploiement.

<figure><img src="image_38.png" /><figcaption>Figure 29: Logo Amarisoft.</figcaption></figure>

### 5.2.3. Wireshark

Wireshark est l'analyseur de protocole réseau le plus utilisé et le
plus utilisé au monde. Il vous permet de voir ce qui se passe sur votre
réseau à un niveau microscopique et constitue la norme de facto (et
souvent de jure) dans de nombreuses entreprises.

<figure><img src="image_39.png" /><figcaption>Figure 30: Logo Wireshark.</figcaption></figure>
5.2.4. Python

Le langage de programmation utilisé pour effectuer la
simulation est le Python. Python a été utilisé du fait de ses nombreux
modules utiles pour la manipulation de fichiers et de chaines de
caractères, utiles pour analyser les fichiers de journalisation.

<figure><img src="image_38.png" /><figcaption>Figure 31: Logo Python.</figcaption></figure>

5.2.5. HyberTone SIMBank scheduler

C'est un service compatible avec des systèmes Linux, proposé par HyberTone qui permet de contrôler et d'organiser les équipements de la SIMBox. Une fois installé dans un ordinateur celui-ci devient un SIM Server capable d'orchestrer la fraude à la SIMBox.

SYNTHÈSE

Dans cette dernière partie dédiée à la modélisation de notre solution, il a été question
pour nous de présenter l'architecture du réseau qui nous devions réaliser ; pour chacune des
situations de fraude que nous avons présentées. Nous avons également présenté les conditions
expérimentales ainsi que les prérequis matériels et logiciels pour réaliser cette expérience.
5.2.4. Python

Le langage de programmation utilisé pour effectuer la
simulation est le Python. Python a été utilisé du fait de ses nombreux
modules utiles pour la manipulation de fichiers et de chaines de
caractères, utiles pour analyser les fichiers de journalisation.

<figure><img src="image_40.png" /><figcaption>Figure 31: Logo Python.</figcaption></figure>

5.2.5. HyberTone SIMBank scheduler

C'est un service compatible avec des systèmes Linux, proposé par HyberTone qui permet de contrôler et d'organiser les équipements de la SIMBox. Une fois installé dans un ordinateur celui-ci devient un SIM Server capable d'orchestrer la fraude à la SIMBox.

SYNTHÈSE

Dans cette dernière partie dédiée à la modélisation de notre solution, il a été question
pour nous de présenter l'architecture du réseau qui nous devions réaliser ; pour chacune des
situations de fraude que nous avons présentées. Nous avons également présenté les conditions
expérimentales ainsi que les prérequis matériels et logiciels pour réaliser cette expérience.
# CHAPITRE III : RÉSULTATS ET DISCUSSIONS

## DESCRIPTION

Dans ce chapitre nous présenterons les résultats de l'expérience que nous avons menée pour différents cas de fraude à la SIMBox et nous comparons les résultats obtenus afin de conclure au sujet de l'efficacité de la méthode de détection utilisée.

## PLAN :

<table><tr><td>1. Résultats de la station de base</td><td>72</td></tr><tr><td>2. Latence de la Procédure d'attachement au réseau</td><td>74</td></tr><tr><td>2.1. Latence par type d'UE</td><td>75</td></tr><tr><td>2.2. Impact de la connexion IP entre équipements SIMBox sur la latence au niveau LTE</td><td>75</td></tr><tr><td>2.3. Impact de la configuration de la SIMBox</td><td>78</td></tr><tr><td>3. Observation détaillée de la signalisation</td><td>80</td></tr><tr><td>4. Bilan des expériences</td><td>81</td></tr></table>

Mémoire de fin d'études en vue de l'obtention du Diplôme d'Ingénieur de Conception en Télécommunications
# CHAPITRE III : RÉSULTATS ET DISCUSSIONS

## DESCRIPTION

Dans ce chapitre nous présenterons les résultats de l'expérience que nous avons menée pour différents cas de fraude à la SIMBox et nous comparons les résultats obtenus afin de conclure au sujet de l'efficacité de la méthode de détection utilisée.

## PLAN :

<table><tr><td>1. Résultats de la station de base</td><td>72</td></tr><tr><td>2. Latence de la Procédure d'attachement au réseau</td><td>74</td></tr><tr><td>2.1. Latence par type d'UE</td><td>75</td></tr><tr><td>2.2. Impact de la connexion IP entre équipements SIMBox sur la latence au niveau LTE</td><td>75</td></tr><tr><td>2.3. Impact de la configuration de la SIMBox</td><td>78</td></tr><tr><td>3. Observation détaillée de la signalisation</td><td>80</td></tr><tr><td>4. Bilan des expériences</td><td>81</td></tr></table>

Mémoire de fin d'études en vue de l'obtention du Diplôme d'Ingénieur de Conception en Télécommunications
# 1. RESULTATS DE LA STATION DE BASE

La station de base AMARI callbox, nous permet de visualiser l'activité en temps réel du réseau autant au niveau de la station de base qu'au niveau des équipements du cœur de réseau. Mais ici nous nous focalisons sur la station de base.

<figure><img src="image_39.png" /><figcaption>Figure 32: Interface graphique d'Amarisoft callbox.</figcaption></figure>

Cette capture d'écran nous montre l'activité d'un utilisateur pendant sa procédure d'attachement au réseau. Mais on remarque que le flux de données est très important il faut pouvoir extraire les informations dont nous avons besoin. On peut voir des informations importantes telles que :

* **Time** : le temps d'envoi ou de réception selon que l'on soit en UL ou en DL
# 1. RESULTATS DE LA STATION DE BASE

La station de base AMARI callbox, nous permet de visualiser l'activité en temps réel du réseau autant au niveau de la station de base qu'au niveau des équipements du cœur de réseau. Mais ici nous nous focalisons sur la station de base.

<figure><img src="image_41.png" /><figcaption>Figure 32: Interface graphique d'Amarisoft callbox.</figcaption></figure>

Cette capture d'écran nous montre l'activité d'un utilisateur pendant sa procédure d'attachement au réseau. Mais on remarque que le flux de données est très important il faut pouvoir extraire les informations dont nous avons besoin. On peut voir des informations importantes telles que :

* **Time** : le temps d'envoi ou de réception selon que l'on soit en UL ou en DL
* **RAN** : Nous donne la couche qui traite le message

* **UE_ID** : L'identifiant de l'UE dans le système

* **Cell** : L'identifiant de la cellule

* **SFN** : le System Frame Number

* **RNTI** : le RNTI de l'utilisateur dans la cellule

* **Info** : nous donne des informations sur l'opération effectuée

* **Message** : qui donne le contenu du message de signalisation envoyé

Ces informations ne sont pas toutes utiles pour nous. La donnée clé est le temps, par lequel
nous allons inférer la latence. Il nous faut reformatter ces messages pour extraire ce que l'on
veut. Pour ce faire nous avons téléchargé des fichiers de journalisation de la station de base,
que nous avons fourni en entrée dans des scripts qui nous permettent d'avoir des détails plus
approfondis dans les données. Le fichier de journalisation est un fichier formatté en JSON.
Nous pouvons voir les caractéristiques complètes de la station de base ainsi que le format des
messages de signalisation dans l'entête du fichier.

```
# lteenb version 2021-06-17, gcc 9.2.1
# Licensed to 'Télécom ParisTech' [8a6a4cbd5be14f9b18453920b31dbc669779fc827a1d128fca]
# SMP bandwidth=10.0/40 PRACH=1 DRBs=1 RF0=1/1
# Log file format:
# time layer dir ue_id {cell_id rnti sfn channel:} message
# Cell 0x01: earfcn=3350 PCI=1 mode=FDD
# DL: n_rb DL=25 cyclic_prefix=0
# UL: n_rb UL=25 cyclic_prefix=0 prach_config_index=4 prach_freq_offset=2 delta_pucch_shift=2 n_rb_cqi=1 n_cs_an=0
# PUCCH allocation:
# Type RBs n
# 2/2a/2b 1 6
# Start of PUCCH ACK/NACK=11
# RBs reserved for PUCCH: 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
# SR resource count=220
# CQI resource count=240
# SRS resources: offsets=8 freqs=5 total=80
# GBR limits: DL=2.356 Mre/s UL=2.492 Mre/s
# Started
```

<caption>Figure 33: Capture d'écran de l'Entête du fichier de journalisation de l'eNodeB.</caption>

Le corps du fichier commence à la connexion de l'eNodeB à l'interface S1 qui le relie avec le
réseau cœur. Et la suite est constituée de l'activité des utilisateurs.
* **RAN** : Nous donne la couche qui traite le message

* **UE_ID** : L'identifiant de l'UE dans le système

* **Cell** : L'identifiant de la cellule

* **SFN** : le System Frame Number

* **RNTI** : le RNTI de l'utilisateur dans la cellule

* **Info** : nous donne des informations sur l'opération effectuée

* **Message** : qui donne le contenu du message de signalisation envoyé

Ces informations ne sont pas toutes utiles pour nous. La donnée clé est le temps, par lequel
nous allons inférer la latence. Il nous faut reformatter ces messages pour extraire ce que l'on
veut. Pour ce faire nous avons téléchargé des fichiers de journalisation de la station de base,
que nous avons fourni en entrée dans des scripts qui nous permettent d'avoir des détails plus
approfondis dans les données. Le fichier de journalisation est un fichier formatté en JSON.
Nous pouvons voir les caractéristiques complètes de la station de base ainsi que le format des
messages de signalisation dans l'entête du fichier.

```
# lteenb version 2021-06-17, gcc 9.2.1
# Licensed to 'Télécom ParisTech' [8a6a4cbd5be14f9b18453920b31dbc669779fc827a1d128fca]
# SMP bandwidth=10.0/40 PRACH=1 DRBs=1 RF0=1/1
# Log file format:
# time layer dir ue_id {cell_id rnti sfn channel:} message
# Cell 0x01: earfcn=3350 PCI=1 mode=FDD
# DL: n_rb DL=25 cyclic_prefix=0
# UL: n_rb UL=25 cyclic_prefix=0 prach_config_index=4 prach_freq_offset=2 delta_pucch_shift=2 n_rb_cqi=1 n_cs_an=0
# PUCCH allocation:
# Type RBs n
# 2/2a/2b 1 6
# Start of PUCCH ACK/NACK=11
# RBs reserved for PUCCH: 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
# SR resource count=220
# CQI resource count=240
# SRS resources: offsets=8 freqs=5 total=80
# GBR limits: DL=2.356 Mre/s UL=2.492 Mre/s
# Started
```

<caption>Figure 33: Capture d'écran de l'Entête du fichier de journalisation de l'eNodeB.</caption>

Le corps du fichier commence à la connexion de l'eNodeB à l'interface S1 qui le relie avec le
réseau cœur. Et la suite est constituée de l'activité des utilisateurs.
```
# Started
14:01:32.961 [S1AP] - Connecting to 127.0.1.100:36412
14:01:33.509 [S1AP] - Connected to 127.0.1.100:36412
14:01:33.509 [S1AP] TO -- 127.0.1.100:36412 S1 setup request
initiatingMessage: {
  procedureCode id=S1Setup,
  criticality reject,
  value {
    protocolIEs {
      {
        id id-Global-ENB-ID,
        criticality reject,
        value {
          pLMNIdentity '09F107'H,
          eNB-ID macroENB-ID: '1A2D0'H
        }
      },
      {
        id id-eNBname,
        criticality ignore,
        value "enb1a2d0"
      }
    }
  }
```

<caption>Figure 34: Capture d'écran du début de l'activité de l'eNodeB : connexion à l'interface S1</caption>

La première étape de notre traitement reformate le fichier de manière à ressortir uniquement les événements élémentaires (les messages de la forme « *time layer dir ue_id {cell_id rnti sfn channel:}* »). Une fois appliquée à notre fichier (Figure 35), on peut voir les étapes de la procédure d'attachement. Une fois ce fichier obtenu, nous calculons les latences à partir des données temporelles fournies par ce fichier de traces à partir des équations (1) et (2).

```
[16:41:27.178 [MAC] - 0001 01 Allocating new UE
[16:41:27.188 [PHY] UL 0001 01 003d 935.5 PUSCH: harq=3 prb=2:4 symb=0:13 CW0: tb_len=11 mod=2 rv_idx=0 retx=0 crc=OK snr=12.1 epre=-118.4 ta=0.7
[16:41:27.188 [MAC] UL 0001 01 PAD: len=0 PAD: len=0 SBSR: lcg=0 b=0 LCID=0 len=6
[16:41:27.188 [RRC] UL 0001 01 CCCH: RRC connection request
[16:41:27.188 [RRC] DL 0001 01 CCCH: RRC connection setup
[16:41:27.188 [PHY] DL 0001 01 003d 935.9 PHICH: group=2 seq=0 hi=1
[16:41:27.188 [MAC] DL 0001 01 UEURI: 5c fc b6 90 5c f6 LCID=0 len=26 PAD: len=1
[16:41:27.188 [PHY] DL 0001 01 003d 935.9 PDSCH: harq=0 k1=4 prb=0:7 tx=div CW0: tb_len=37 mod=2 rv_idx=0 retx=0
[16:41:27.188 [PHY] DL 0001 01 003d 935.9 PDCCH: cce_index=4/12 L=4 dci=1a
[16:41:27.196 [PHY] UL 0001 01 - 936.3 PUCCH: format=1A n=15 ack=1 snr=-0.1 epre=-135.3
[16:41:27.213 [PHY] UL 0001 01 - 938.0 PUCCH: format=1 n=0 sr=1 snr=-0.0 epre=-135.3
[16:41:27.213 [PHY] DL 0001 01 003d 938.4 PDCCH: cce_index=0/12 L=4 dci=0
[16:41:27.221 [PHY] UL 0001 01 003d 938.8 PUSCH: harq=4 prb=2:5 symb=0:14 CW0: tb_len=109 mod=4 rv_idx=0 retx=0 crc=OK snr=23.5 epre=-104.9 ta=0.7
[16:41:27.222 [MAC] UL 0001 01 SBSR: lcg=0 b=0 PHR: ph=30 LCID:1 len=86 PAD: len=16
[16:41:27.222 [RLC] UL 0001 SRB1 D/C=1 RF=0 P=1 FI=00 E=0 SN=0
[16:41:27.222 [PDCP] UL 0001 SRB1 SN=0
[16:41:27.222 [RRC] UL 0001 01 DCCH: RRC connection setup complete
[16:41:27.222 [NAS] UL 0001 EMM: Attach request
[16:41:27.222 [PHY] DL 0001 01 003d 939.2 PHICH: group=2 seq=0 hi=1
[16:41:27.222 [RLC] DL 0001 SRB1 D/C=0 CPT=0 ACK_SN=1
[16:41:27.222 [MAC] DL 0001 01 LCID:1 len=2 PAD: len=4
[16:41:27.222 [PHY] DL 0001 01 003d 939.2 PDSCH: harq=0 k1=4 prb=23:2 tx=div CW0: tb_len=9 mod=2 rv_idx=0 retx=0
[16:41:27.222 [PHY] DL 0001 01 003d 939.2 PDCCH: cce_index=4/12 L=4 dci=1a
[16:41:27.222 [NAS] DL 0001 EMM: Authentication request
[16:41:27.222 [RRC] DL 0001 01 DCCH: DL information transfer
```

<caption>Figure 35: Capture d'écran du début de la procédure d'attachement pour un utilisateur.</caption>

## 2. LATENCE DE LA PROCEDURE D'ATTACHEMENT AU RESEAU

Après application de notre script nous pouvons avoir les résultats de la latence en fonction des différents scénarios que nous sommes donnés.
```
# Started
14:01:32.961 [S1AP] - Connecting to 127.0.1.100:36412
14:01:33.509 [S1AP] - Connected to 127.0.1.100:36412
14:01:33.509 [S1AP] TO -- 127.0.1.100:36412 S1 setup request
initiatingMessage: {
  procedureCode id=S1Setup,
  criticality reject,
  value {
    protocolIEs {
      {
        id id-Global-ENB-ID,
        criticality reject,
        value {
          pLMNIdentity '09F107'H,
          eNB-ID macroENB-ID: '1A2D0'H
        }
      },
      {
        id id-eNBname,
        criticality ignore,
        value "enb1a2d0"
      }
    }
  }
```

<caption>Figure 34: Capture d'écran du début de l'activité de l'eNodeB : connexion à l'interface S1</caption>

La première étape de notre traitement reformate le fichier de manière à ressortir uniquement les événements élémentaires (les messages de la forme « *time layer dir ue_id {cell_id rnti sfn channel:}* »). Une fois appliquée à notre fichier (Figure 35), on peut voir les étapes de la procédure d'attachement. Une fois ce fichier obtenu, nous calculons les latences à partir des données temporelles fournies par ce fichier de traces à partir des équations (1) et (2).

```
[16:41:27.178 [MAC] - 0001 01 Allocating new UE
[16:41:27.188 [PHY] UL 0001 01 003d 935.5 PUSCH: harq=3 prb=2:4 symb=0:13 CW0: tb_len=11 mod=2 rv_idx=0 retx=0 crc=OK snr=12.1 epre=-118.4 ta=0.7
[16:41:27.188 [MAC] UL 0001 01 PAD: len=0 PAD: len=0 SBSR: lcg=0 b=0 LCID=0 len=6
[16:41:27.188 [RRC] UL 0001 01 CCCH: RRC connection request
[16:41:27.188 [RRC] DL 0001 01 CCCH: RRC connection setup
[16:41:27.188 [PHY] DL 0001 01 003d 935.9 PHICH: group=2 seq=0 hi=1
[16:41:27.188 [MAC] DL 0001 01 UEURI: 5c fc b6 90 5c f6 LCID=0 len=26 PAD: len=1
[16:41:27.188 [PHY] DL 0001 01 003d 935.9 PDSCH: harq=0 k1=4 prb=0:7 tx=div CW0: tb_len=37 mod=2 rv_idx=0 retx=0
[16:41:27.188 [PHY] DL 0001 01 003d 935.9 PDCCH: cce_index=4/12 L=4 dci=1a
[16:41:27.196 [PHY] UL 0001 01 - 936.3 PUCCH: format=1A n=15 ack=1 snr=-0.1 epre=-135.3
[16:41:27.213 [PHY] UL 0001 01 - 938.0 PUCCH: format=1 n=0 sr=1 snr=-0.0 epre=-135.3
[16:41:27.213 [PHY] DL 0001 01 003d 938.4 PDCCH: cce_index=0/12 L=4 dci=0
[16:41:27.221 [PHY] UL 0001 01 003d 938.8 PUSCH: harq=4 prb=2:5 symb=0:14 CW0: tb_len=109 mod=4 rv_idx=0 retx=0 crc=OK snr=23.5 epre=-104.9 ta=0.7
[16:41:27.222 [MAC] UL 0001 01 SBSR: lcg=0 b=0 PHR: ph=30 LCID:1 len=86 PAD: len=16
[16:41:27.222 [RLC] UL 0001 SRB1 D/C=1 RF=0 P=1 FI=00 E=0 SN=0
[16:41:27.222 [PDCP] UL 0001 SRB1 SN=0
[16:41:27.222 [RRC] UL 0001 01 DCCH: RRC connection setup complete
[16:41:27.222 [NAS] UL 0001 EMM: Attach request
[16:41:27.222 [PHY] DL 0001 01 003d 939.2 PHICH: group=2 seq=0 hi=1
[16:41:27.222 [RLC] DL 0001 SRB1 D/C=0 CPT=0 ACK_SN=1
[16:41:27.222 [MAC] DL 0001 01 LCID:1 len=2 PAD: len=4
[16:41:27.222 [PHY] DL 0001 01 003d 939.2 PDSCH: harq=0 k1=4 prb=23:2 tx=div CW0: tb_len=9 mod=2 rv_idx=0 retx=0
[16:41:27.222 [PHY] DL 0001 01 003d 939.2 PDCCH: cce_index=4/12 L=4 dci=1a
[16:41:27.222 [NAS] DL 0001 EMM: Authentication request
[16:41:27.222 [RRC] DL 0001 01 DCCH: DL information transfer
```

<caption>Figure 35: Capture d'écran du début de la procédure d'attachement pour un utilisateur.</caption>

## 2. LATENCE DE LA PROCEDURE D'ATTACHEMENT AU RESEAU

Après application de notre script nous pouvons avoir les résultats de la latence en fonction des différents scénarios que nous sommes donnés.
## 2.1. Latence par type d'UE

La Figure 36 ci-dessous présente la latence d'attachement pour chacun des UE dans les cas de SIMBox et de terminaux réguliers comme suit :

* Téléphone Xiaomi Redmi Note 9 (bleu)

* Téléphone Huawei Mate 8 (rouge)

* Gateway connectée au SIM Server en local (jaune)

* Gateway seule (vert)

<figure><img src="image_40.png" /><figcaption>Figure 36: Latence de l'attachement par type d'UE.</figcaption></figure>

On observe une différence considérable (plus de **4000 ms**) entre le cas où il y a des communications IP entre équipements de la SIMBox, et les cas où la carte SIM est physiquement connectée.

## 2.2. Impact de la connexion IP entre équipements SIMBox sur la latence au niveau LTE.

### 2.2.1. Impact du débit de l'interface Ethernet du SIM Server

Ici nous comparons la latence de l'attachement, pour différents débits de connexion sur l'interface Ethernet du SIM Server, pour y voir son impact sur la latence dans la communication au niveau de la station de base. Ceci serait un argument supplémentaire pour créditer la
## 2.1. Latence par type d'UE

La Figure 36 ci-dessous présente la latence d'attachement pour chacun des UE dans les cas de SIMBox et de terminaux réguliers comme suit :

* Téléphone Xiaomi Redmi Note 9 (bleu)

* Téléphone Huawei Mate 8 (rouge)

* Gateway connectée au SIM Server en local (jaune)

* Gateway seule (vert)

<figure><img src="image_42.png" /><figcaption>Figure 36: Latence de l'attachement par type d'UE.</figcaption></figure>

On observe une différence considérable (plus de **4000 ms**) entre le cas où il y a des communications IP entre équipements de la SIMBox, et les cas où la carte SIM est physiquement connectée.

## 2.2. Impact de la connexion IP entre équipements SIMBox sur la latence au niveau LTE.

### 2.2.1. Impact du débit de l'interface Ethernet du SIM Server

Ici nous comparons la latence de l'attachement, pour différents débits de connexion sur l'interface Ethernet du SIM Server, pour y voir son impact sur la latence dans la communication au niveau de la station de base. Ceci serait un argument supplémentaire pour créditer la
méthode utilisée. Pour ce faire nous avons fait varier ledit débit à 10, 100 et 1000 Mbps à l'aide d'**ethtool**. Nous avons observé le débit moyen réel de notre connexion à l'aide de speedtest un package Ubuntu.

<figure><img src="image_41.png" /><figcaption>(a) 10 Mbps</figcaption></figure>

<figure><img src="image_42.png" /><figcaption>(b) 100 Mbps</figcaption></figure>

<figure><img src="image_43.png" /><figcaption>(c) 1000 Mbps</figcaption></figure>

Figure 37: Débits réels, moyens mesurés sur l'interface Ethernet du SIM Server pour différents débits 10, 100 et 1000 Mbps.

<figure><img src="image_44.png" /></figure>

Figure 38: Evolution de la latence de la procédure d'attachement en fonction du débit.
méthode utilisée. Pour ce faire nous avons fait varier ledit débit à 10, 100 et 1000 Mbps à l'aide d'**ethtool**. Nous avons observé le débit moyen réel de notre connexion à l'aide de speedtest un package Ubuntu.

<figure><img src="image_43.png" /><figcaption>(a) 10 Mbps</figcaption></figure>

<figure><img src="image_44.png" /><figcaption>(b) 100 Mbps</figcaption></figure>

<figure><img src="image_45.png" /><figcaption>(c) 1000 Mbps</figcaption></figure>

Figure 37: Débits réels, moyens mesurés sur l'interface Ethernet du SIM Server pour différents débits 10, 100 et 1000 Mbps.

<figure><img src="image_46.png" /></figure>

Figure 38: Evolution de la latence de la procédure d'attachement en fonction du débit.
On peut y voir que la latence croît lorsque le débit de la connexion entre équipements de la SIMBox diminue. Mais il reste toujours largement au-dessus des **4000 ms pour le meilleur débit possible** et de ce fait, toujours aussi loin de celle des terminaux réguliers.

### 2.2.2. Impact de l'utilisation d'internet entre équipements de la SIMBox (effet de la latence IP)

Dans ces résultats nous avons comparé pour des débits similaires la latence obtenue lorsque les équipements de la SIMBox sont connectés localement et lorsqu'ils sont connectés via internet. En effet plusieurs paramètres influencent la qualité de la connexion dont le débit, la latence, la gigue, et le séquençage des paquets.

<table><caption>Tableau 7: Tableau récapitulatif des caractéristiques de qualité des connexions IP</caption><thead><tr><td>Variable</td><td>Via Internet</td><td>En local</td><td>Minimum requis</td></tr></thead><tbody><tr><td>Débit descendant/montant)</td><td>95.36/4.90 Mbps</td><td>13.01/86.54 Mbps</td><td>11 Kbps</td></tr><tr><td>Latence</td><td>9.38 ms</td><td>2.36 ms</td><td>300 ms</td></tr><tr><td>Gigue</td><td>0.17 ms</td><td>0.02 ms</td><td>/</td></tr><tr><td>Taux de perte de paquets</td><td>0.0%</td><td>0.0%</td><td>1%</td></tr></tbody></table>

<figure><img src="image_45.png" /><figcaption>Figure 39: Latence de la procédure d'attachement dans cas de connexion en local et via internet entre équipements de la SIMBox.</figcaption></figure>
On peut y voir que la latence croît lorsque le débit de la connexion entre équipements de la SIMBox diminue. Mais il reste toujours largement au-dessus des **4000 ms pour le meilleur débit possible** et de ce fait, toujours aussi loin de celle des terminaux réguliers.

### 2.2.2. Impact de l'utilisation d'internet entre équipements de la SIMBox (effet de la latence IP)

Dans ces résultats nous avons comparé pour des débits similaires la latence obtenue lorsque les équipements de la SIMBox sont connectés localement et lorsqu'ils sont connectés via internet. En effet plusieurs paramètres influencent la qualité de la connexion dont le débit, la latence, la gigue, et le séquençage des paquets.

<table><caption>Tableau 7: Tableau récapitulatif des caractéristiques de qualité des connexions IP</caption><thead><tr><td>Variable</td><td>Via Internet</td><td>En local</td><td>Minimum requis</td></tr></thead><tbody><tr><td>Débit descendant/montant)</td><td>95.36/4.90 Mbps</td><td>13.01/86.54 Mbps</td><td>11 Kbps</td></tr><tr><td>Latence</td><td>9.38 ms</td><td>2.36 ms</td><td>300 ms</td></tr><tr><td>Gigue</td><td>0.17 ms</td><td>0.02 ms</td><td>/</td></tr><tr><td>Taux de perte de paquets</td><td>0.0%</td><td>0.0%</td><td>1%</td></tr></tbody></table>

<figure><img src="image_47.png" /><figcaption>Figure 39: Latence de la procédure d'attachement dans cas de connexion en local et via internet entre équipements de la SIMBox.</figcaption></figure>
On peut donc observer que quand une connexion à internet est utilisée (comme dans la plupart des cas réels d'utilisation de la SIMBox) la latence observée est beaucoup plus élevée à débit de connexion équivalent sur les interfaces. Cela du fait de l'influence des routeurs intermédiaires et de la distance entre les deux sites.

## 2.3. Impact de la configuration de la SIMBox

Dans cette expérience nous avons essayé de voir l'impact des configurations que les fraudeurs pourraient faire dans le but de diminuer la latence que l'on pourrait observer au niveau de la station de base. Nous avons noté deux configurations qui pourraient le faire :

* L'utilisation d'UDP pour les communications avec le SIM Server

* L'utilisation du format « short command » pour les données de carte SIM

### 2.3.1. Utilisation d'UDP

Nous avons observé le comportement de la latence lorsque UDP était utilisé comparativement à lorsque l'on utilisait TCP, à un même débit de 100 Mbps.

<figure><img src="image_46.png" /><figcaption>Figure 40: Impact du protocole de la couche de transport utilisé entre équipements de la SIMBox sur la latence de la procédure d'attachement</figcaption></figure>

On se rend ainsi compte que la différence entre les deux latences est très faible. Ce qui rend des conclusions difficiles, mais toujours est que dans les deux cas on reste au-dessus du seuil des 4000 ms et de ce fait largement supérieur à la latence dans le cas des terminaux réguliers.
On peut donc observer que quand une connexion à internet est utilisée (comme dans la plupart des cas réels d'utilisation de la SIMBox) la latence observée est beaucoup plus élevée à débit de connexion équivalent sur les interfaces. Cela du fait de l'influence des routeurs intermédiaires et de la distance entre les deux sites.

## 2.3. Impact de la configuration de la SIMBox

Dans cette expérience nous avons essayé de voir l'impact des configurations que les fraudeurs pourraient faire dans le but de diminuer la latence que l'on pourrait observer au niveau de la station de base. Nous avons noté deux configurations qui pourraient le faire :

* L'utilisation d'UDP pour les communications avec le SIM Server

* L'utilisation du format « short command » pour les données de carte SIM

### 2.3.1. Utilisation d'UDP

Nous avons observé le comportement de la latence lorsque UDP était utilisé comparativement à lorsque l'on utilisait TCP, à un même débit de 100 Mbps.

<figure><img src="image_48.png" /><figcaption>Figure 40: Impact du protocole de la couche de transport utilisé entre équipements de la SIMBox sur la latence de la procédure d'attachement</figcaption></figure>

On se rend ainsi compte que la différence entre les deux latences est très faible. Ce qui rend des conclusions difficiles, mais toujours est que dans les deux cas on reste au-dessus du seuil des 4000 ms et de ce fait largement supérieur à la latence dans le cas des terminaux réguliers.
2.3.2. Impact du format de données de carte SIM

Dans cette expérience nous avons changé le format des données de carte SIM pour
observer le comportement de la latence dans chacun des cas. Il en existe deux dans le cas
de la gateway Hybertone [29] que nous avons utilisé pendant l'expérience :

*   **Long command** : qui envoie des instructions plus longues de la SIMBank vers la gateway. C'est l'option utilisée par défaut dans les gateways HyberTone ;

*   **Short command** : qui est une alternative à format plus court qui selon le constructeur, serait plus compatible avec la commande à distance.

<figure><img src="image_47.png" /><figcaption>Figure 41: Impact du format de données des cartes SIM sur la latence, dans le cas de TCP.</figcaption></figure>

<figure><img src="image_48.png" /><figcaption>Figure 42: Impact du format de données des cartes SIM sur la latence, dans le cas de UDP.</figcaption></figure>
2.3.2. Impact du format de données de carte SIM

Dans cette expérience nous avons changé le format des données de carte SIM pour
observer le comportement de la latence dans chacun des cas. Il en existe deux dans le cas
de la gateway Hybertone [29] que nous avons utilisé pendant l'expérience :

*   **Long command** : qui envoie des instructions plus longues de la SIMBank vers la gateway. C'est l'option utilisée par défaut dans les gateways HyberTone ;

*   **Short command** : qui est une alternative à format plus court qui selon le constructeur, serait plus compatible avec la commande à distance.

<figure><img src="image_49.png" /><figcaption>Figure 41: Impact du format de données des cartes SIM sur la latence, dans le cas de TCP.</figcaption></figure>

<figure><img src="image_50.png" /><figcaption>Figure 42: Impact du format de données des cartes SIM sur la latence, dans le cas de UDP.</figcaption></figure>
On constate ainsi que l'utilisation du format short command peut réduire la latence, mais on remarque qu'on demeure au-dessus du seuil des **4000 ms**, toujours aussi largement supérieur au cas des terminaux réguliers.

3. OBSERVATION DETAILLEE DE LA
SIGNALISATION

Dans cette partie nous présentons le résultat obtenu lorsque l'on se penche plus en détail dans chaque étape de la procédure d'attachement dans laquelle le terminal communique avec la station de base. Nous recherchons ainsi à déterminer les opérations qui créent ce décalage entre les latences dans les cas de SIMBox et dans les cas d'utilisateurs normaux.

<figure><img src="image_49.png" /><figcaption>Figure 43: Latence de la procédure d'attachement étape par étape pour chaque type d'UE.</figcaption></figure>
On constate ainsi que l'utilisation du format short command peut réduire la latence, mais on remarque qu'on demeure au-dessus du seuil des **4000 ms**, toujours aussi largement supérieur au cas des terminaux réguliers.

3. OBSERVATION DETAILLEE DE LA
SIGNALISATION

Dans cette partie nous présentons le résultat obtenu lorsque l'on se penche plus en détail dans chaque étape de la procédure d'attachement dans laquelle le terminal communique avec la station de base. Nous recherchons ainsi à déterminer les opérations qui créent ce décalage entre les latences dans les cas de SIMBox et dans les cas d'utilisateurs normaux.

<figure><img src="image_51.png" /><figcaption>Figure 43: Latence de la procédure d'attachement étape par étape pour chaque type d'UE.</figcaption></figure>
Nous pouvons ainsi observer que l'étape la plus chronophage, dans la procédure d'attachement c'est l'authentification. Cela s'observe autant pour la SIMBox que pour les terminaux ordinaires (Figure 43). On note d'ailleurs qu'il constitue plus de **80%** de la durée d'attachement.

## 4. BILAN DES EXPERIENCES

Le Tableau 8, résume toutes les expériences effectuées et les résultats obtenus.

<table><caption>Tableau 8: Tableau récapitulatif des expériences menées</caption><thead><tr><td>Expérience</td><td>Démarche</td><td>Résultats</td></tr></thead><tbody><tr><td>Xiaomi Redmi Note 9</td><td>Test d'attachement au réseau 4G et observation de la latence.</td><td>La latence oscille autour de 550 ms.</td></tr><tr><td>Huawei Mate 8</td><td>Test d'attachement au réseau 4G et observation de la latence.</td><td><ul><li>La latence du téléphone Huawei est sensiblement égale à celle du téléphone Xiaomi.</li><li>On a ainsi un ordre de grandeur de la latence des terminaux (moins de 600 ms)</li></ul></td></tr><tr><td>SIMBox complète (Variation de la qualité des liens IP)</td><td>1- Test d'attachement en local pour des débits différents (10,100,1000 Mbps)<br>2- Test d'attachement en utilisant internet (100 Mbps) pour voir l'impact de la latence IP.</td><td><ul><li>La latence de la SIMBox complète est largement supérieure à celle des terminaux réguliers (augmentation de plus de 500%)</li><li>La latence au niveau LTE diminue quand le débit augmente au niveau IP</li><li>La latence au niveau LTE augmente quand la latence augmente au niveau IP</li></ul></td></tr></tbody></table>

Mémoire de fin d'études en vue de l'obtention du Diplôme d'Ingénieur de Conception en Télécommunications
Nous pouvons ainsi observer que l'étape la plus chronophage, dans la procédure d'attachement c'est l'authentification. Cela s'observe autant pour la SIMBox que pour les terminaux ordinaires (Figure 43). On note d'ailleurs qu'il constitue plus de **80%** de la durée d'attachement.

## 4. BILAN DES EXPERIENCES

Le Tableau 8, résume toutes les expériences effectuées et les résultats obtenus.

<table><caption>Tableau 8: Tableau récapitulatif des expériences menées</caption><thead><tr><td>Expérience</td><td>Démarche</td><td>Résultats</td></tr></thead><tbody><tr><td>Xiaomi Redmi Note 9</td><td>Test d'attachement au réseau 4G et observation de la latence.</td><td>La latence oscille autour de 550 ms.</td></tr><tr><td>Huawei Mate 8</td><td>Test d'attachement au réseau 4G et observation de la latence.</td><td><ul><li>La latence du téléphone Huawei est sensiblement égale à celle du téléphone Xiaomi.</li><li>On a ainsi un ordre de grandeur de la latence des terminaux (moins de 600 ms)</li></ul></td></tr><tr><td>SIMBox complète (Variation de la qualité des liens IP)</td><td>1- Test d'attachement en local pour des débits différents (10,100,1000 Mbps)<br>2- Test d'attachement en utilisant internet (100 Mbps) pour voir l'impact de la latence IP.</td><td><ul><li>La latence de la SIMBox complète est largement supérieure à celle des terminaux réguliers (augmentation de plus de 500%)</li><li>La latence au niveau LTE diminue quand le débit augmente au niveau IP</li><li>La latence au niveau LTE augmente quand la latence augmente au niveau IP</li></ul></td></tr></tbody></table>
<table><tr><td>SIMBox complète<br>(Changement de<br>protocole de la<br>couche de transport)</td><td>Tests d'attachement en utilisant<br>TCP puis UDP comme protocole<br>de la couche de transport pour les<br>communications entre<br>équipements de la SIMBox</td><td>Aucune conclusion possible, du fait de<br>l'encodage des données dans un protocole de la<br>couche application inconnu.</td></tr><tr><td>SIMBox complète<br>(Changement du<br>format de données<br>de la carte SIM)</td><td>Tests d'attachement en utilisant<br>les formats de données de carte<br>SIM, « short command » puis<br>« long command ».</td><td>Le format « short command » peut réduire la<br>latence, mais on reste dans des valeurs<br>supérieures au seuil des 3000 ms</td></tr></table>

## SYNTHÈSE

Au terme de ce chapitre où il était question de présenter les résultats de notre travail. Il ressort que la méthode que nous avons explorée nous permet de classifier les utilisateurs de fraude à la SIMBox des utilisateurs normaux sur la base. La différence de latence pendant la période d'attachement est toujours supérieure à **4000 ms** soit 4 secondes, que l'on pourrait utiliser comme seuil de détection.
<table><tr><td>SIMBox complète<br>(Changement de<br>protocole de la<br>couche de transport)</td><td>Tests d'attachement en utilisant<br>TCP puis UDP comme protocole<br>de la couche de transport pour les<br>communications entre<br>équipements de la SIMBox</td><td>Aucune conclusion possible, du fait de<br>l'encodage des données dans un protocole de la<br>couche application inconnu.</td></tr><tr><td>SIMBox complète<br>(Changement du<br>format de données<br>de la carte SIM)</td><td>Tests d'attachement en utilisant<br>les formats de données de carte<br>SIM, « short command » puis<br>« long command ».</td><td>Le format « short command » peut réduire la<br>latence, mais on reste dans des valeurs<br>supérieures au seuil des 3000 ms</td></tr></table>

SYNTHÈSE

Au terme de ce chapitre où il était question de présenter les résultats de notre travail. Il ressort que la méthode que nous avons explorée nous permet de classifier les utilisateurs de fraude à la SIMBox des utilisateurs normaux sur la base. La différence de latence pendant la période d'attachement est toujours supérieure à **4000 ms** soit 4 secondes, que l'on pourrait utiliser comme seuil de détection.
CONCLUSION GÉNÉRALE ET PERSPECTIVES

La tâche que nous avons eu à mener, a été de déployer et de configurer une architecture matérielle composée d'équipements de la SIMBox, pour tester une méthode de détection de la fraude basée sur l'analyse de la signalisation.

Dans le but de pouvoir réduire les pertes économiques chez les opérateurs de réseau mobiles. Nous avons d'abord situé le contexte en présentant l'écosystème des opérateurs de télécommunications, et celui de la fraude à la SIMBox, puis nous avons présenté les enjeux liés à ladite fraude pour les opérateurs. Il a ensuite été question pour nous de nous étendre sur le travail scientifique effectué dans la détection de la fraude à la SIMBox. Tout en présentant les limites de ces méthodes, nous avons pu mener des expériences sur la méthode de détection basée sur la signalisation afin de pouvoir montrer tout l'intérêt de cette méthode pourtant peu explorée dans la littérature.

Nous avons donc au terme de ce travail :

* Déployé et configuré la SIMBox dans un contexte expérimental ;

* Testé différentes architectures de SIMBox ;

* Analysé la signalisation entre station de base et équipements de la SIMBox ;

* Montré que la latence liée à la procédure d'attachement constitue un critère de classification fiable de la SIMBox par rapport aux utilisateurs réguliers.

En termes de perspectives pour le futur dans la recherche à ce sujet nous suggérons :

* Une étude approfondie des procédures de sécurité pendant l'attachement dans le cas de la SIMBox ;

* L'implémentation au niveau des stations de base d'algorithmes de classification basée sur la latence lors de la procédure d'attachement ;

* Une étude approfondie des communications et protocoles utilisés entre équipements de la SIMBox ;
CONCLUSION GÉNÉRALE ET PERSPECTIVES

La tâche que nous avons eu à mener, a été de déployer et de configurer une architecture matérielle composée d'équipements de la SIMBox, pour tester une méthode de détection de la fraude basée sur l'analyse de la signalisation.

Dans le but de pouvoir réduire les pertes économiques chez les opérateurs de réseau mobiles. Nous avons d'abord situé le contexte en présentant l'écosystème des opérateurs de télécommunications, et celui de la fraude à la SIMBox, puis nous avons présenté les enjeux liés à ladite fraude pour les opérateurs. Il a ensuite été question pour nous de nous étendre sur le travail scientifique effectué dans la détection de la fraude à la SIMBox. Tout en présentant les limites de ces méthodes, nous avons pu mener des expériences sur la méthode de détection basée sur la signalisation afin de pouvoir montrer tout l'intérêt de cette méthode pourtant peu explorée dans la littérature.

Nous avons donc au terme de ce travail :

* Déployé et configuré la SIMBox dans un contexte expérimental ;

* Testé différentes architectures de SIMBox ;

* Analysé la signalisation entre station de base et équipements de la SIMBox ;

* Montré que la latence liée à la procédure d'attachement constitue un critère de classification fiable de la SIMBox par rapport aux utilisateurs réguliers.

En termes de perspectives pour le futur dans la recherche à ce sujet nous suggérons :

* Une étude approfondie des procédures de sécurité pendant l'attachement dans le cas de la SIMBox ;

* L'implémentation au niveau des stations de base d'algorithmes de classification basée sur la latence lors de la procédure d'attachement ;

* Une étude approfondie des communications et protocoles utilisés entre équipements de la SIMBox ;
RÉFÉRENCES BIBLIOGRAPHIQUES

[1] GSMA, «L'Economie Mobile - Afrique Subsaharienne,» 2019.

[2] CFCA, «Communications Fraud Control Association – Fraud Loss Survey 2019,» 2019.
[En ligne]. Available: https://cfca.org/wp-content/uploads/2021/02/CFCA-2019-Fraud-Loss-Survey.pdf. [Accès le 6 Septembre 2021].

[3] CFCA, «2017 Global Fraud Loss Survey,» 2017.

[4] C. NCC Policy and E. A. Department, «An assessment of international voice traffic termination rates,» Juillet 2015.

[5] A. Ecofin, Cameroun : 22,2 milliards FCfa de pertes en 2015 sur les appels téléphoniques frauduleux par Simbox,» 9 Octobre 2015. [En ligne]. Available: https://www.agenceecofin.com/gestion-publique/0910-32980-cameroun-22-2-milliards-fcfa-de-pertes-en-2015-sur-les-appels-telephoniques-frauduleux-par-simbox. [Accès le 6 Septembre 2021].

[6] M. Yelland, *Fraud in mobile networks*, Computer Fraud & Security, vol. 2013, no. 3, pp. 5–9, 2013.

[7] L. S. R. I. (TRI), *White paper: Network protocol analysis: A new tool for blocking international bypass fraud before revenue is lost*, Tech.Rep, 2015.

[8] R. Kreher et K. Gaenger, *LTE Signaling : Troubleshooting and Performance Measurement (2e éd)*, Wiley, 2016.

[9] EFORT, *Architectures de Réseaux et de Services de Télécommunication Réseaux, Entités de Réseau, Technologies, Services*, 2011. [En ligne]. Available: https://sznaty2.wixsite.com/efort3/tutorial. [Accès le 6 Septembre 2021].

[10] ARCEP, *Parlons 5G : toutes vos questions sur la 5G*, 25 Mai 2021. [En ligne]. Available: https://www.arcep.fr/nos-sujets/parlons-5g-toutes-vos-questions-sur-la-5g.html. [Accès le 6 Septembre 2021].
RÉFÉRENCES BIBLIOGRAPHIQUES

[1] GSMA, «L'Economie Mobile - Afrique Subsaharienne,» 2019.

[2] CFCA, «Communications Fraud Control Association – Fraud Loss Survey 2019,» 2019. [En ligne]. Available: https://cfca.org/wp-content/uploads/2021/02/CFCA-2019-Fraud-Loss-Survey.pdf. [Accès le 6 Septembre 2021].

[3] CFCA, «2017 Global Fraud Loss Survey,» 2017.

[4] C. NCC Policy and E. A. Department, «An assessment of international voice traffic termination rates,» Juillet 2015.

[5] A. Ecofin, Cameroun : 22,2 milliards FCfa de pertes en 2015 sur les appels téléphoniques frauduleux par Simbox,» 9 Octobre 2015. [En ligne]. Available: https://www.agenceecofin.com/gestion-publique/0910-32980-cameroun-22-2-milliards-fcfa-de-pertes-en-2015-sur-les-appels-telephoniques-frauduleux-par-simbox. [Accès le 6 Septembre 2021].

[6] M. Yelland, *Fraud in mobile networks*, Computer Fraud & Security, vol. 2013, no. 3, pp. 5–9, 2013.

[7] L. S. R. I. (TRI), *White paper: Network protocol analysis: A new tool for blocking international bypass fraud before revenue is lost*, Tech.Rep, 2015.

[8] R. Kreher et K. Gaenger, *LTE Signaling : Troubleshooting and Performance Measurement (2e éd)*, Wiley, 2016.

[9] EFORT, *Architectures de Réseaux et de Services de Télécommunication Réseaux, Entités de Réseau, Technologies, Services*, 2011. [En ligne]. Available: https://sznaty2.wixsite.com/efort3/tutorial. [Accès le 6 Septembre 2021].

[10] ARCEP, *Parlons 5G : toutes vos questions sur la 5G*, 25 Mai 2021. [En ligne]. Available: https://www.arcep.fr/nos-sujets/parlons-5g-toutes-vos-questions-sur-la-5g.html. [Accès le 6 Septembre 2021].
[11] 3GPP, *ITU-R Confers IMT-Advanced (4G) Status to 3GPP LTE*, 20 Octobre 2010. [En ligne]. Available: https://www.3gpp.org/news-events/3gpp-news/1319-ITU-R-Confers-IMT-Advanced-4G-Status-to-3GPP-LTE. [Accès le 6 Septembre 2021].

[12] J. O. Oludayo, *The Future of LTE: The Femtocells perspective*, School of Electrical Engineering, Thesis submitted for examination for the degree of Master of Science in Technology Espoo 24.11.2013, 2013.

[13] EFORT, LTE + SAE = EPS Principes et Architecture, 2009. [En ligne]. Available: https://sznaty2.wixsite.com/efort3/tutorial. [Accès le 16 Septembre 2021].

[14] A. ABDELGHANI, MÉMOIRE PRÉSENTÉ À L'UNIVERSITÉ DU QUÉBEC À TROIS-RIVIÈRES COMME EXIGENCE PARTIELLE DE LA MAÎTRISE EN MATHÉMATIQUES ET INFORMATIQUE APPLIQUÉES, IMPACT DES INTERFÉRENCES DE LA COUCHE PHYSIQUE SUR LA COUCHE MAC, UNIVERSITÉ DU QUÉBEC, JUIN 2011.

[15] Wikipedia, *Signalisation (télécommunication)*, [En ligne]. Available: https://fr.wikipedia.org/wiki/Signalisation_(t%C3%A9l%C3%A9communication). [Accès le 16 Septembre 2021].

[16] 3GPP, *3GPP TS 24.301*, *Non-Access-Stratum (NAS) protocol for Evolved Packet Packet System (EPS)*, 2014.

[17] 3GPP, 3GPP TS 36.331, *Evolved Universal Terrestrial Radio Access (E-UTRA); RadioResource Control (RRC); Protocol specification (Release 8)*.

[18] 3GPP, *3GPP TS 36.322, Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control (RLC) protocol specification (Release 8)*.

[19] 3GPP, *3GPP TS 36.321*, *Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification (Release8)*.

[20] Wikipedia, *Voix sur IP*, [En ligne]. Available: https://fr.wikipedia.org/wiki/Voix_sur_IP. [Accès le Octobre 2021].

[21] 3CX, *Avantages d'un IPBX •• Système téléphonique VoIP*, [En ligne]. Available: https://www.3cx.fr/voip-sip/ip-pbx-overview/. [Accès le Octobre 2021].
[11] 3GPP, *ITU-R Confers IMT-Advanced (4G) Status to 3GPP LTE*, 20 Octobre 2010. [En ligne]. Available: https://www.3gpp.org/news-events/3gpp-news/1319-ITU-R-Confers-IMT-Advanced-4G-Status-to-3GPP-LTE. [Accès le 6 Septembre 2021].

[12] J. O. Oludayo, *The Future of LTE: The Femtocells perspective*, School of Electrical Engineering, Thesis submitted for examination for the degree of Master of Science in Technology Espoo 24.11.2013, 2013.

[13] EFORT, LTE + SAE = EPS Principes et Architecture, 2009. [En ligne]. Available: https://sznaty2.wixsite.com/efort3/tutorial. [Accès le 16 Septembre 2021].

[14] A. ABDELGHANI, MÉMOIRE PRÉSENTÉ À L'UNIVERSITÉ DU QUÉBEC À TROIS-RIVIÈRES COMME EXIGENCE PARTIELLE DE LA MAÎTRISE EN MATHÉMATIQUES ET INFORMATIQUE APPLIQUÉES, IMPACT DES INTERFÉRENCES DE LA COUCHE PHYSIQUE SUR LA COUCHE MAC, UNIVERSITÉ DU QUÉBEC, JUIN 2011.

[15] Wikipedia, *Signalisation (télécommunication)*, [En ligne]. Available: https://fr.wikipedia.org/wiki/Signalisation_(t%C3%A9l%C3%A9communication). [Accès le 16 Septembre 2021].

[16] 3GPP, 3GPP TS 24.301, *Non-Access-Stratum (NAS) protocol for Evolved Packet Packet System (EPS)*, 2014.

[17] 3GPP, 3GPP TS 36.331, *Evolved Universal Terrestrial Radio Access (E-UTRA); RadioResource Control (RRC); Protocol specification (Release 8)*.

[18] 3GPP, 3GPP TS 36.322, *Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control (RLC) protocol specification (Release 8)*.

[19] 3GPP, 3GPP TS 36.321, *Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification (Release8)*.

[20] Wikipedia, *Voix sur IP*, [En ligne]. Available: https://fr.wikipedia.org/wiki/Voix_sur_IP. [Accès le Octobre 2021].

[21] 3CX, *Avantages d'un IPBX •• Système téléphonique VoIP*, [En ligne]. Available: https://www.3cx.fr/voip-sip/ip-pbx-overview/. [Accès le Octobre 2021].
[22] Recommendation ITU-T. H.323, SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS Infrastructure of audiovisual services – Systems and terminal equipment for audiovisual services, 2009.

[23] 3CX, *Qu'est-ce que le protocole H.323 •• Définition*, [En ligne]. Available: https://www.3cx.fr/voip-sip/h323/. [Accès le Octobre 2021].

[24] E. NOUREDDINE et S. a. CHAFA, *Étude et Mise en place D'une Solution VoIP Sécurisée, Mémoire de fin d'études En vue de l'obtention Du Diplôme De Master en Electronique Option : Réseaux et Télécommunications*, Université Mouloud Mammeri De Tizi-Ouzou, 2014.

[25] 3CX, *H.323 Communication Example H323*, [En ligne]. Available: http://www.en voipforo com/H323/H323_example.php. [Accès le 6 Octobre 2021].

[26] F. Goffinet, *Architecture SIP*, Septembre 2020. [En ligne]. Available: https://sip.goffinet.org/sip/architecture/. [Accès le 6 Octobre 2021].

[27] B. KASSE, *Etude et mise en place d'un système de communication de VOIP: appliqué à un PABX IP open source*, Université Cheikh Anta Diop de Dakar, 2006.

[28] A. Kouam, A. Carneiro Viana et A. Tchana, SIMBox bypass frauds in cellular networks: a survey. [*Research Report*], INRIA. 2021. (hal-03105845v3), 2021.

[29] U. Murad et G. Pinkas, “Unsupervised profiling for identifying superimposed fraud,” in *Principles of Data Mining and Knowledge Discovery*, J. M. Zytkow and J. Rauch, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 1999, pp. 251–261.».

[30] S. Rosset, U. Murad, E. Neumann, Y. Idan et G. Pinkas, “Discovery of fraud rules for telecommunications—challenges and solutions.” New York, NY, USA: Association for Computing Machinery Available,» 1999. [En ligne]. Available: https://doi.org/10.1145/312129.312303. [Accès le 16 Septembre 2021].

[31] I. Murynets, M. Zabarankin, R. P. Jover et A. Panaiga, *Analysis and detection of simbox fraud in mobility networks*, IEEE INFOCOM 2014 - IEEE Conference on Computer Communications, April 2014, pp. 1519–1526.
[22] Recommendation ITU-T. H.323, SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS Infrastructure of audiovisual services – Systems and terminal equipment for audiovisual services, 2009.

[23] 3CX, *Qu'est-ce que le protocole H.323 •• Définition*, [En ligne]. Available: https://www.3cx.fr/voip-sip/h323/. [Accès le Octobre 2021].

[24] E. NOUREDDINE et S. a. CHAFA, *Étude et Mise en place D'une Solution VoIP Sécurisée, Mémoire de fin d'études En vue de l'obtention Du Diplôme De Master en Electronique Option : Réseaux et Télécommunications*, Université Mouloud Mammeri De Tizi-Ouzou, 2014.

[25] 3CX, H.323 Communication Example H323, [En ligne]. Available: http://www.en voipforo com/H323/H323_example.php. [Accès le 6 Octobre 2021].

[26] F. Goffinet, Architecture SIP, Septembre 2020. [En ligne]. Available: https://sip.goffinet.org/sip/architecture/. [Accès le 6 Octobre 2021].

[27] B. KASSE, *Etude et mise en place d'un système de communication de VOIP: appliqué à un PABX IP open source*, Université Cheikh Anta Diop de Dakar, 2006.

[28] A. Kouam, A. Carneiro Viana et A. Tchana, SIMBox bypass frauds in cellular networks: a survey. [Research Report], INRIA. 2021. (hal-03105845v3), 2021.

[29] U. Murad et G. Pinkas, “Unsupervised profiling for identifying superimposed fraud,” in *Principles of Data Mining and Knowledge Discovery*, J. M. ' Zytkow and J. Rauch, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 1999, pp. 251–261.».

[30] S. Rosset, U. Murad, E. Neumann, Y. Idan et G. Pinkas, “Discovery of fraud rules for telecommunications—challenges and solutions.” New York, NY, USA: Association for Computing Machinery Available,» 1999. [En ligne]. Available: https://doi.org/10.1145/312129.312303. [Accès le 16 Septembre 2021].

[31] I. Murynets, M. Zabarankin, R. P. Jover et A. Panaiga, *Analysis and detection of simbox fraud in mobility networks*, IEEE INFOCOM 2014 - IEEE Conference on Computer Communications, April 2014, pp. 1519–1526.
[32] L. Shenzhen HyberTone Technology Co., GoIP User Manual, 2016. [En ligne].
Available: http://www.hybertone.com/uploadfile/download/20140304125318422.pdf .
[Accès le 1 Juillet 2021].

[33] L. Shenzhen HyberTone Technology Co., User Manual for SMB32 Remote SIM Card Controller, 2016. [En ligne]. Available: http://www.hybertone.com/uploadfile/download/20110914030122550.pdf. [Accès le 1 Juillet 2021].

[34] Telegeography, Cellular Subscribers to Hit 9 Billion in 2026, [En ligne]. Available: https://blog.telegeography.com/cellular-subscribers-to-hit-9-billion-in-2026 . [Accès le 16 Septembre 2021].

[35] F. Okumbor, N. Anthony et. A. A. J. Olokunde, Grappling with the challenges of interconnect bypass fraud, IOSR Journal of Mobile Computing and Application (IOSR-JMCA), vol. 6, pp. 35 – 41, Jan - Feb 2019.

[36] OECD, Access to mobile services and proof of identity 2019: Assessing the impact on digital and financial inclusion, 2019.

[37] L. Taylor, CFCA Administration, Founder, Lateral Alliances, “Putting telecom fraud loss into perspective...”, [En ligne]. Available: https://cfca.org/putting-telecom-fraud-loss-into-perspective/. [Accès le 16 Septembre 2021].

[38] M. R. AlBougha, Comparing data mining classification algorithms in detection of simbox fraud, 2016.

[39] 3GPP, 3GPP TS 36.300 V10.12.0 (2014-12), Décembre 2014. [En ligne]. Available: https://www.arib.or.jp/english/html/overview/doc/STD-T104v3_20/5_Appendix/Rel10/36/36300-ac0.pdf. [Accès le 16 Septembre 2021].

[40] HW Platforms – Network, Mobility and Services, [En ligne]. Available: https://nms.telecom-paristech.fr/research/plateforms/. [Accès le 16 Septembre 2021].
[32] L. Shenzhen HyberTone Technology Co., GoIP User Manual, 2016. [En ligne].
Available: http://www.hybertone.com/uploadfile/download/20140304125318422.pdf .
[Accès le 1 Juillet 2021].

[33] L. Shenzhen HyberTone Technology Co., User Manual for SMB32 Remote SIM Card Controller, 2016. [En ligne]. Available: http://www.hybertone.com/uploadfile/download/20110914030122550.pdf. [Accès le 1 Juillet 2021].

[34] Telegeography, Cellular Subscribers to Hit 9 Billion in 2026, [En ligne]. Available: https://blog.telegeography.com/cellular-subscribers-to-hit-9-billion-in-2026 . [Accès le 16 Septembre 2021].

[35] F. Okumbor, N. Anthony et. A. A. J. Olokunde, Grappling with the challenges of interconnect bypass fraud, IOSR Journal of Mobile Computing and Application (IOSR-JMCA), vol. 6, pp. 35 – 41, Jan - Feb 2019.

[36] OECD, Access to mobile services and proof of identity 2019: Assessing the impact on digital and financial inclusion, 2019.

[37] L. Taylor, CFCA Administration, Founder, Lateral Alliances, “Putting telecom fraud loss into perspective...”, [En ligne]. Available: https://cfca.org/putting-telecom-fraud-loss-into-perspective/. [Accès le 16 Septembre 2021].

[38] M. R. AlBougha, Comparing data mining classification algorithms in detection of simbox fraud, 2016.

[39] 3GPP, 3GPP TS 36.300 V10.12.0 (2014-12), Décembre 2014. [En ligne]. Available: https://www.arib.or.jp/english/html/overview/doc/STD-T104v3_20/5_Appendix/Rel10/36/36300-ac0.pdf. [Accès le 16 Septembre 2021].

[40] HW Platforms – Network, Mobility and Services, [En ligne]. Available: https://nms.telecom-paristech.fr/research/plateforms/. [Accès le 16 Septembre 2021].
# ANNEXE

## FABRICANTS DE SIMBOX ET SPECIFICITES

<table><caption>Tableau 9 : Fonctionnalités de la SIMBox en fonction des différents fabricants</caption><thead><tr><th>Fonctionalité HBS</th><th>Rôle</th><th>Paramètre</th><th>Valeur</th><th>Fabricant proposant la function</th></tr></thead><tbody><tr><td rowspan="5">Rotation de SIM</td><td rowspan="5">Trafic distribué parmi les cartes SIM</td><td rowspan="3">Method for selecting the next SIM card</td><td>round-robin method</td><td>Hybertone, Antrax</td></tr><tr><td>random method</td><td>Hybertone, Portech</td></tr><tr><td>statistic-based factor</td><td>Hybertone, Antrax, Dinstar</td></tr><tr><td rowspan="2">Trigger to switch SIM cards</td><td>statistic-based factor</td><td>Antrax</td></tr><tr><td>per time period</td><td>Hybertone, Antrax, Portech</td></tr><tr><td rowspan="5">Limitation de l'activité des SIM</td><td rowspan="5">Utilisation normale des carte SIM (heures, contacts, etc)</td><td rowspan="5">Type of limitation</td><td>Threshold method</td><td>Antrax</td></tr><tr><td>Activity script method</td><td>Hybertone, Dinstar, Ejoin, Portech</td></tr><tr><td>Parameter limitation</td><td>Antrax</td></tr><tr><td>Parameter limitation per time period</td><td>Dinstar</td></tr><tr><td>Time limitation</td><td>Hybertone, Antrax, Ejoin, Dinstar, Portech</td></tr><tr><td rowspan="5">Migration de SIM</td><td rowspan="5">Simulation de mouvements humains</td><td rowspan="5">Method for selecting the next GSM channel</td><td>Manually fixed method</td><td>Hybertone</td></tr><tr><td>Any except previous</td><td>Antrax, Hybertone</td></tr><tr><td>Any except previous zone</td><td>Hybertone</td></tr><tr><td>Any gateway</td><td>Antrax</td></tr><tr><td>Specified order</td><td>Antrax</td></tr><tr><td rowspan="6">Changement/verouillage de station de base</td><td rowspan="6">Simulation de mouvements humains</td><td rowspan="6">Method for selecting base station</td><td>Manually</td><td>Portech</td></tr><tr><td>Default</td><td>Hybertone, Ejoin, Portech, Dinstar</td></tr><tr><td>Fixed</td><td>Hybertone, Dinstar</td></tr><tr><td>Random</td><td>Dinstar</td></tr><tr><td>Poll</td><td>Hybertone, Ejoin</td></tr><tr><td>Advanced</td><td>Hybertone, Dinstar</td></tr><tr><td rowspan="3">IMEI modifiable</td><td rowspan="3">Une seule carte SIM par équipement</td><td>Method for changes at GSM channel</td><td>Manual editing</td><td>Hybertone</td></tr><tr><td>IMEI auto change</td><td>Hybertone</td></tr><tr><td>Method for changes SIM slots</td><td>Manual editing</td><td>Ejoin, Antrax</td></tr></tbody></table>

Mémoire de fin d'études en vue de l'obtention du Diplôme d'Ingénieur de Conception en Télécommunications
# ANNEXE

## FABRICANTS DE SIMBOX ET SPECIFICITES

<table><caption>Tableau 9 : Fonctionnalités de la SIMBox en fonction des différents fabricants</caption><thead><tr><th>Fonctionalité HBS</th><th>Rôle</th><th>Paramètre</th><th>Valeur</th><th>Fabricant proposant la function</th></tr></thead><tbody><tr><td rowspan="5">Rotation de SIM</td><td rowspan="5">Trafic distribué parmi les cartes SIM</td><td rowspan="3">Method for selecting the next SIM card</td><td>round-robin method</td><td>Hybertone, Antrax</td></tr><tr><td>random method</td><td>Hybertone, Portech</td></tr><tr><td>statistic-based factor</td><td>Hybertone, Antrax, Dinstar</td></tr><tr><td rowspan="2">Trigger to switch SIM cards</td><td>statistic-based factor</td><td>Antrax</td></tr><tr><td>per time period</td><td>Hybertone, Antrax, Portech</td></tr><tr><td rowspan="5">Limitation de l'activité des SIM</td><td rowspan="5">Utilisation normale des carte SIM (heures, contacts, etc)</td><td rowspan="5">Type of limitation</td><td>Threshold method</td><td>Antrax</td></tr><tr><td>Activity script method</td><td>Hybertone, Dinstar, Ejoin, Portech</td></tr><tr><td>Parameter limitation</td><td>Antrax</td></tr><tr><td>Parameter limitation per time period</td><td>Dinstar</td></tr><tr><td>Time limitation</td><td>Hybertone, Antrax, Ejoin, Dinstar, Portech</td></tr><tr><td rowspan="5">Migration de SIM</td><td rowspan="5">Simulation de mouvements humains</td><td rowspan="5">Method for selecting the next GSM channel</td><td>Manually fixed method</td><td>Hybertone</td></tr><tr><td>Any except previous</td><td>Antrax, Hybertone</td></tr><tr><td>Any except previous zone</td><td>Hybertone</td></tr><tr><td>Any gateway</td><td>Antrax</td></tr><tr><td>Specified order</td><td>Antrax</td></tr><tr><td rowspan="6">Changement/verouillage de station de base</td><td rowspan="6">Simulation de micro mouvements humains</td><td rowspan="6">Method for selecting base station</td><td>Manually</td><td>Portech</td></tr><tr><td>Default</td><td>Hybertone, Ejoin, Portech, Dinstar</td></tr><tr><td>Fixed</td><td>Hybertone, Dinstar</td></tr><tr><td>Random</td><td>Dinstar</td></tr><tr><td>Poll</td><td>Hybertone, Ejoin</td></tr><tr><td>Advanced</td><td>Hybertone, Dinstar</td></tr><tr><td rowspan="3">IMEI modifiable</td><td rowspan="3">Une seule carte SIM par équipement</td><td>Method for changes at GSM channel</td><td>Manual editing</td><td>Hybertone</td></tr><tr><td>IMEI auto change</td><td>Hybertone</td></tr><tr><td>Method for changes SIM slots</td><td>Manual editing</td><td>Ejoin, Antrax</td></tr></tbody></table>

Mémoire de fin d'études en vue de l'obtention du Diplôme d'Ingénieur de Conception en Télécommunications
<table><tr><td></td><td></td><td></td><td>Random IMEI</td><td>Antrax, Dinstar</td></tr><tr><td></td><td></td><td></td><td>Prefix IMEI</td><td>Ejoin, Antrax</td></tr><tr><td></td><td></td><td></td><td>Registry IMEI</td><td>Antrax</td></tr><tr><td></td><td></td><td></td><td>IMEI based on TAC</td><td>Antrax, Dinstar</td></tr><tr><td rowspan="3">Utilisation d'autres services mobiles</td><td rowspan="3">Utilisation normale d'autres services mobiles (data, SMS,etc)</td><td rowspan="3">Services used</td><td>Internet</td><td>Ejoin, Dinstar, Antrax</td></tr><tr><td>USSD commands</td><td>Hybertone, Ejoin, Dinstar, Antrax, Portech, 2N voiceblue</td></tr><tr><td>SMS</td><td>Hybertone, Ejoin, Dinstar, Antrax, Portech 2N voiceblue</td></tr><tr><td rowspan="2">Family list</td><td rowspan="2">Liste de contacts limités</td><td rowspan="2">Services used</td><td>SMS inter- sending</td><td>Ejoin</td></tr><tr><td>Inter-calling</td><td>Ejoin</td></tr><tr><td rowspan="4">Redirection d'appels</td><td rowspan="4">Réponse d'un complice humain aux appels</td><td rowspan="4">Forwarding conditions</td><td>Unconditional</td><td>Ejoin</td></tr><tr><td>Busy</td><td>Ejoin</td></tr><tr><td>No reachable</td><td>Hybertone, Dinstar</td></tr><tr><td>No reply</td><td>Hybertone, Dinstar</td></tr></table>
<table><tr><td></td><td></td><td></td><td>Random IMEI</td><td>Antrax, Dinstar</td></tr><tr><td></td><td></td><td></td><td>Prefix IMEI</td><td>Ejoin, Antrax</td></tr><tr><td></td><td></td><td></td><td>Registry IMEI</td><td>Antrax</td></tr><tr><td></td><td></td><td></td><td>IMEI based on TAC</td><td>Antrax, Dinstar</td></tr><tr><td rowspan="3">Utilisation d'autres services mobiles</td><td rowspan="3">Utilisation normale d'autres services mobiles (data, SMS,etc)</td><td rowspan="3">Services used</td><td>Internet</td><td>Ejoin, Dinstar, Antrax</td></tr><tr><td>USSD commands</td><td>Hybertone, Ejoin, Dinstar, Antrax, Portech, 2N voiceblue</td></tr><tr><td>SMS</td><td>Hybertone, Ejoin, Dinstar, Antrax, Portech 2N voiceblue</td></tr><tr><td rowspan="2">Family list</td><td rowspan="2">Liste de contacts limités</td><td rowspan="2">Services used</td><td>SMS inter- sending</td><td>Ejoin</td></tr><tr><td>Inter-calling</td><td>Ejoin</td></tr><tr><td rowspan="4">Redirection d'appels</td><td rowspan="4">Réponse d'un complice humain aux appels</td><td rowspan="4">Forwarding conditions</td><td>Unconditional</td><td>Ejoin</td></tr><tr><td>Busy</td><td>Ejoin</td></tr><tr><td>No reachable</td><td>Hybertone, Dinstar</td></tr><tr><td>No reply</td><td>Hybertone, Dinstar</td></tr></table>