# [TC3] TP3 - RAN
###### tags: `RAN`, `S2`, `TC3`

## Intro Cochon d'Inde

## Etude des codes d'étalement sous ***MatLab***

### Simulation 1 : Codes d’étalement UMTS

#### **Q1**

On a 3,84 Mchip/s, donc le temps d'un chip c'est 1/3,84 * 10^6^ (2,6 * 10^-7^s). 1 chip, c'est la subdivision d'un symbole où le code correcteur est constant.

Le Spreading Factor (SF), c'est le nombre de chips utilisés pour transmettre un symbole.

On a donc le Temps Symbole : Ts = SF*Tchip

Le Sample Time est lié au temps symbole.
Le **Zero-order Hold** permet de garder une valeur en entrée pendant un certain temps (ici TimeChip)

Le bloc **OVSF *(Orthogonal Variable Spreading Factor)* Code Generator** permet de générer des familles de codes orthogonaux, sur 8-bits.

#### **Q2**


##### Signaux

| 1 | 1 | 1 | 1 |
| --- | --- | --- | --- |
| **1** | **-1** | **1** | **-1** |
| **1** | **1** | **-1** | **-1** |
| **1** | **-1** | **-1** | **1** |

#### **Q3**

On a rajouté un upsample et un filtre FIR discret, dont les coéfficients sont les mêmes que ceux du code orthogonal.


### Simulation 2 : Codes d’étalement orthogonaux UMTS

#### **Q1**

Les codes OVSF sont orthogonaux, donc le produit ~scalaire~ deux à deux sont

Il y en a un qui était en vacances ouias voilà, il m'a dit
C'est dans un mois cette affaire
me mets pas la pression stp
oups, mais tranquille tu déménages pas
D'ailleurs Noé, t'as trouvé un coloc ?

OUI !
Un mec de centrale Nantes qui à l'air d'être un sacré cake mais qui reste d'avril à aout donc c'est 100% parfait.

"un gros charo" selon une pote de l'autre Noé

un mec de centrale nantes, c'est original ça
il est beau ?
Tu t'es fait un avis ?
il a l'air de faire le boy, mais en même temps s'il fait une liste de je sais pas quoi c'est fait exprès
Il a l'air de faire du sport aussi =>
"20h par semaine, 2 entrainements par jour, 3 le week-end, je mange equilibré..."
Ah
Oui
au moins tu mangeras des trucs stylés

Ou alors juste du Tofu
Et c'est pas fun

cf l'image qui suit

Va voir sur Insa'appartement "Thomas Hue"
Mais quel abus

ex : <(1,1,1,1) ,(1,-1,1,-1)> = 1 * 1 + 1 * (-1) + 1 * 1 + 1 * (-1) = 0

#### **Q2**

Il faut attribuer un code différent à chaque utilisateur. De plus, lorsqu'un code est attribué, tous ceux qui découlent de ce dernier sont inutilisables.

#### **Q3**


+ **Windowed Integrator**: intègre sur une fenêtre glissante de taille *SF*
+ **Downsample**: on downsample pour réduire la fréquence des changements
+ **Saturation**: on limite l'output à [-1,1]
+ **Bipolar to Unipolar converter**: convertit de bipolar à unipolar

##### Résultats


**TimeChip** = 2.60e^-7^
**SF** = 4

débit chip = 1/2.60e^-7^ = 3.84 Mchip/s
débit symbole = débit chip/4 = 961 Ksymb/s

### Simulation 3 : Codes d’étalement orthogonaux UMTS

#### **Q1**

Les délais peuvent simuler une situation de canal multi-chemins (multi-trajet, donc des chemins de longuer différentes).


#### **Q2**

On y arrive en fait.

#### **Q3**

C'est un canal multi-chemin.

#### **Q4**

On voit que la mauvaise synchro est due aux auto-interferences liées au canal multi-chemin.

On remarque le point faible de OVSF : sans synchronisation, l'orthogonalité n'est plus garantie.

#### **Q5**

On utilise les scramblings codes.

### Simulation 4 : Code de scrambling UMTS

#### **Q1**

On a rajouté un générateur de pseudo-bruit (scrambling) pour identifer chaque émetteur. Cela permet d'obtenir des codes pseudo-orthogonaux.
On identifie alors dans une cellule chaque utilisateur par son code OVSF (les utilisateurs sont synchronisés avec la station de base), puis on identifie chaque cellule (la station de base de la cellule) par son scrambling code.

Chaque PN Sequence Generator possède le même générateur polynomial, mais c'est l'état initial qui change.


L'orthogonalité n'est pas parfaite, on parle de pseudo orthogonalité (le produit ~scalaire~ n'est pas exactement à 0)

#### **Q2**

On ajoute une deuxième voie.


On récupère bien les données, on ne voit des erreurs, par contre la synchronisation n'est plus parfaite

#### **Q3**

On décommente les délais.


On récupère une partie des données mais il y a des erreurs.

#### **Q4**

On enlève les délais, mais on active le canal multi-chemin.


On récupère bien les données, mais la synchronisation est niquée.

#### **Q5**

On calcule le BER.


Sans canal, on a un BER de 0.

#### **Q6**

Avec les délais activés. On met le *receive delay* à 2.


On a toujours un BER de 0.

#### **Q7**

En rajoutant le canal AWGN.


On a un BER d'environ 1,1%.

## ANALYSE D’UN SIGNAL DOWNLINK SOUS ***VSA***

### Réglage du logiciel VSA

#### **Q1**

La largeur de bande est de 4,78 MHz.


#### **Q2**

Fréquence = URFCN / 5 = 2112,8 MHz

Avec le code de scrambling 17

Avec le code de scrambling 24

On ne peut récupérer les données.

### Mesures et analyses du canal P-CPICH

#### **Q1**