# RAN - TP3 - G2

###### tags : `RAN` `TP`

## Partie 1 : ETUDE DES CODES D’ETALEMENT SOUS MATLAB
### 1.3.1 Simulation 1 : Codes d’étalement UMTS
**Q1**.
Le modèle comporte 4 générateur de code OVSF, on a donc un SF à 4, condition minimale pour avoir 4 codes.
**TimeChip = 1/3.84e6** du fait du débit chip, constant et fixé.
**TimeSymbol = TimeChip * SF** -> Etalement de chaque impulsion avec le Spreading Factor

Il est logique que le temps symbole soit le sample time des générateurs de séquence aléatoires (il doivent générer une séquence à chaque symbole).

zero-holder : Il transforme les échantillons en signal continu (garde la valeur de l'échantillon sur toute la durée timechip)

OVSF code generator est, sans surprise, un générateur de code OVSF.

**Q2**

*Sortie du scope*

On peut voir les 4 codes utilisés :+1: :
- 1,1,1,1
- 1,1,-1,-1
- 1,-1,1,-1
- 1,-1,-1,1

On remarque que les signaux sont orthogonaux.
Chaque code OVSF est généré à partir d’une matrice de Hadamard de taille 4.

**Q3**

Il faut enlever le zero holder, puis utiliser le bloc upsample avec un upsample factor de SF, puis discrete FIR filter avec comme coefficients les coeffs du code (1 1 -1 -1 par exemple).



### 1.3.2 Simulation 2 : Codes d’étalement orthogonaux UMTS
**Q1**

Les codes OVSF ne sont orthogonaux que si les émetteurs sont synchrones.

**Q2**

oui(ah bon ?)
Les codes OVSF sont attribués aux utilisateurs en fonction du débit alloué à celui-ci par le réseau : un utilisateur qui a besoin d’un gros débit va utiliser un code court mais peu disponible, un faible débit prendra un code long, codes qui sont disponibles en plus grand nombre.

**Q3**


le window integrator fait une moyenne glissante, il faut choper le pic avec le downsampler avec le bon decemation factor et surtout le bon offset (SF-1 pour choper le pic)


**Q4**

On a bien des scope bruit-less. débit chip = 1/TimeChip ; débit symbole = débit chip / SF

**Q5**

Premier triplet : 1 1 1 1, 1 1 -1 -1, et 1 -1 (c'est ok c'est bruit-less).

**Q6**

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

**Q1**
Cela correspond au scénario où plusieurs mobiles contactent une antenne, contexte de non-synchronisation
=> UPLINK

**Q2**
Pas de synchro donc on ne récupère pas le pic

**Q3**
Multipass => on récupère de la merde

**Q4**

c moch pck ya multipass ki fé nawak ; OVSF é chian pck y fo ètr s1kros pr ètr orthgnl
OSKUR

traduction: Cela n'est guère beau, en raison de la présence de la multitude de chemins. le facteur d'étalement orthogonal et variable se trouve en position de briseur de coquilles, cela étant dû à la nécessité de synchronisation et d'orthogoatalité.


**Q5**

Code de scrambling

### 1.3.4 Simulation 4 : Code de scrambling UMTS

**Q1**
Présence de 2 multiplications :
- OVSF
- Scrambling code formé avec une bruit pseudo RANDOM (même générateur polynomial, états initials différents)


pas d'orthogoatalité parfaite

**Q2**

Ici, comme dans une orgie, on a une suite de bits aléatoires.

Oui on récupère les données, avec quelques erreurs.

**Q3**

channel 2


channel 1 qui est le seul sans délai

On récupère les données avec toujours quelques erreurs.

**Q4**


Pas d'erreurs. (ou vraiment très peu)

## 1.4 PARTIE 2 : ANALYSE D’UN SIGNAL DOWNLINK SOUS VSA

**Q1**
BW =~ 4.5 ~~ 5MHz