Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
59d21ce33f | ||
|
|
cdfed23c69 | ||
|
|
078835e734 | ||
|
|
5d57fc551f | ||
|
|
32b8b39f95 | ||
|
|
7cc3642b40 | ||
|
|
9c687b00b9 | ||
|
|
9242fc7d25 | ||
|
|
73b104f7f2 | ||
|
|
05444c1438 |
No files matched your search
@@ -1,70 +0,0 @@
|
||||
name: Build site
|
||||
|
||||
on:
|
||||
- push
|
||||
- workflow_dispatch
|
||||
|
||||
jobs:
|
||||
build:
|
||||
# NOTE: must match your act_runner labels (e.g. ubuntu-latest, ubuntu-24.04).
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Bootstrap pinned toolchain
|
||||
run: ./scripts/bootstrap.sh
|
||||
|
||||
- name: Build site
|
||||
run: ./scripts/calepin.sh compile site public
|
||||
|
||||
# The official upload-artifact@v4 refuses to run on Gitea (it detects a
|
||||
# non-GitHub server and aborts with GHESNotSupportedError). v3 uses the
|
||||
# artifact API that Gitea implements. On Gitea >= 1.22 with a current
|
||||
# act_runner, christopherhx/gitea-upload-artifact@v4 is a drop-in
|
||||
# replacement if you want the v4 API.
|
||||
- name: Upload site artifact
|
||||
uses: actions/upload-artifact@v3
|
||||
with:
|
||||
name: public
|
||||
path: public/
|
||||
|
||||
deploy:
|
||||
needs: build
|
||||
# Publish only from main; move the gate to publish from another branch.
|
||||
if: github.ref == 'refs/heads/main'
|
||||
# Write access for the automatic Actions token to push the pages branch.
|
||||
permissions:
|
||||
contents: write
|
||||
# NOTE: must match your act_runner labels (e.g. ubuntu-latest, ubuntu-24.04).
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Download site artifact
|
||||
uses: actions/download-artifact@v3
|
||||
with:
|
||||
name: public
|
||||
path: public
|
||||
|
||||
- name: Check artifact layout
|
||||
run: test -f public/index.html
|
||||
|
||||
# Publishing interfaces with prod; it never runs under local act tests
|
||||
# (act sets env.ACT, the Gitea runner does not). The force-push to the
|
||||
# `pages` branch is what triggers the git-pages webhook.
|
||||
- name: Publish to pages branch
|
||||
env:
|
||||
GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }}
|
||||
run: |
|
||||
if [ -z "$GITEA_TOKEN" ]; then
|
||||
echo "::error::Missing GITEA_TOKEN (the automatic Actions token)."
|
||||
exit 1
|
||||
fi
|
||||
cd public
|
||||
git init -q -b pages .
|
||||
git config user.name "Yggdrasil CI"
|
||||
git config user.email "ci@noreply.kb28.ch"
|
||||
git add -A
|
||||
git commit -q -m "Publish site from ${GITHUB_SHA}"
|
||||
repo_host="${GITHUB_SERVER_URL#*://}"
|
||||
repo_host="${repo_host%/}"
|
||||
git push -q --force "https://${GITHUB_REPOSITORY_OWNER}:${GITEA_TOKEN}@${repo_host}/${GITHUB_REPOSITORY}.git" pages
|
||||
@@ -1,10 +0,0 @@
|
||||
# Generated site and pinned toolchain
|
||||
public/
|
||||
tools/
|
||||
|
||||
# Calepin build artifacts
|
||||
.calepin/
|
||||
.calepin-entry.*
|
||||
|
||||
# IDE
|
||||
.idea/
|
||||
@@ -1,20 +0,0 @@
|
||||
# Agent Rules for Yggdrasil Migration
|
||||
|
||||
* **Commit Policy**: Small conventional commits. One logical change per
|
||||
commit, committed only once that step is verified and working. End every
|
||||
commit message with a blank line followed by an
|
||||
`Assisted-by: Delta:zai-glm-5.3` footer.
|
||||
* **Layout**: Sources live in `site/` (`calepin.toml` + `.typ` pages),
|
||||
generated output in `public/` (gitignored), pinned binaries in `tools/`
|
||||
(gitignored), helper scripts in `scripts/`, and the old Docsify
|
||||
documentation stays untouched in `legacy_docs/`.
|
||||
* **Toolchain**: `calepin` (0.0.61) and `typst` (0.15.1) are pinned in
|
||||
`scripts/bootstrap.sh` and downloaded into `tools/` with checksum
|
||||
verification. The build must never depend on global installs. CI installs
|
||||
the same pinned versions by calling the same scripts.
|
||||
* **Verification**: Before committing, run a fresh cycle: `rm -rf tools`,
|
||||
then `just clean`, then `just build` — the build must succeed with no
|
||||
calepin on `PATH`. Verify the served site (`just preview`): home 200,
|
||||
category page 200, sub-page 200, missing page shows the 404 page,
|
||||
`sitemap.xml` present. After every test/clean cycle `git status` must stay
|
||||
clean.
|
||||
@@ -1,27 +0,0 @@
|
||||
# Show the available recipes
|
||||
default:
|
||||
@just --list
|
||||
|
||||
# Bootstrap the pinned calepin + typst binaries into tools/
|
||||
tools:
|
||||
./scripts/bootstrap.sh
|
||||
|
||||
# Compile the site into public/
|
||||
build: tools
|
||||
./scripts/calepin.sh compile site public
|
||||
|
||||
# Build, then serve the site locally
|
||||
preview: build
|
||||
./scripts/calepin.sh serve public
|
||||
|
||||
# Rebuild on change and serve the result
|
||||
watch: tools
|
||||
./scripts/calepin.sh watch site public --serve
|
||||
|
||||
# Remove generated output and build caches
|
||||
clean:
|
||||
./scripts/clean.sh
|
||||
|
||||
# Run the CI workflow locally with act (requires act + docker)
|
||||
ci:
|
||||
act push -W .gitea/workflows/build.yml -j build --artifact-server-path /tmp/act-artifacts
|
||||
@@ -1,88 +1,27 @@
|
||||
# Yggdrasil
|
||||
<header>
|
||||
<h1>Yggdrasil</h1>
|
||||
</header>
|
||||
Yggdrasil is a collections of notes around IT, OT and other geeks stuff
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
Personal knowledge base built as a static website with
|
||||
[Calepin](https://vincentarelbundock.github.io/calepin/), a Typst-based static
|
||||
site generator.
|
||||
# [Bachelor in embedded system](/infotro/)
|
||||
Here notes I take during my bachelor in embedded systems
|
||||
|
||||
## Layout
|
||||
Mainly some topics:
|
||||
- [PTR - Programmation Temps Réel](/infotro/PTR/)
|
||||
- [SDi - Système Distribué](/infotro/SDi/)
|
||||
- [Eln - Électronique](/infotro/Eln/)
|
||||
- [SEm - Systèmes Embarqué](/infotro/SEm/)
|
||||
|
||||
- `site/` — website sources: `calepin.toml` + `.typ` pages
|
||||
- `site/themes/yggdrasil/` — local theme extending the bundled `calepin` theme (scoped sidebars, academic-styled landing)
|
||||
- `public/` — generated site (gitignored)
|
||||
- `tools/` — pinned `calepin` and `typst` binaries (gitignored, downloaded on demand)
|
||||
- `scripts/` — helper scripts used by the Justfile and CI
|
||||
- `legacy_docs/` — the old Docsify documentation, kept unmodified for reference
|
||||
# [Embedded Systems](/Embed/)
|
||||
Here some note specific about some Embedded System
|
||||
- [STM32](/Embed/STM32/)
|
||||
- [nRF](/Embed/nRF/)
|
||||
|
||||
## Quick start
|
||||
# [Working environment at HES-SO](/HES-SO/)
|
||||
Here some note about the working environment at HES-SO
|
||||
|
||||
`just` is the only prerequisite — the toolchain is downloaded and
|
||||
checksum-verified into `tools/` on first use (no global installs, no cargo):
|
||||
|
||||
just # list recipes
|
||||
just tools # download the pinned toolchain into tools/
|
||||
just build # compile site/ into public/
|
||||
just preview # build, then serve the site locally
|
||||
just watch # rebuild on change and serve
|
||||
just clean # remove public/ and build caches
|
||||
just ci # run the CI workflow locally with act (needs act + docker)
|
||||
|
||||
## Adding a page
|
||||
|
||||
Create `site/<category>/<page>.typ`:
|
||||
|
||||
```typst
|
||||
#set document(title: [Page title])
|
||||
#metadata((title: "Page title", translation_key: "category-page")) <website-metadata>
|
||||
|
||||
#title()
|
||||
|
||||
= Page title
|
||||
|
||||
Content…
|
||||
```
|
||||
|
||||
and reference it in `site/calepin.toml`:
|
||||
|
||||
```toml
|
||||
[[sidebar.section.item]]
|
||||
target = "<category>/<page>.typ"
|
||||
```
|
||||
|
||||
Sidebar labels come from the page's `#metadata(...)` line, not from the config.
|
||||
|
||||
Every page also renders a printable PDF twin (`pdf = true` in
|
||||
`calepin.toml`, selectable in the page's view picker). Add `pdf: false` to a
|
||||
page's `#metadata(...)` to skip its PDF, as `404.typ` does.
|
||||
|
||||
## Adding a category
|
||||
|
||||
1. Create `site/<category>/` with an `index.typ`, using
|
||||
`#metadata((title: "Overview", ...))` for its sidebar label.
|
||||
2. Add a `[[sidebar.section]]` named after the category in `calepin.toml`,
|
||||
listing the index page and its sub-pages.
|
||||
3. Add a `[[menus.main]]` entry with the category's `index.typ` as `target`
|
||||
and the category name as `label` (e.g. `Home`, `IT`), so it appears in the
|
||||
top navigation bar. The `label` is required here because the index page's
|
||||
metadata title is `Overview`.
|
||||
|
||||
Pages inside a category show only that category's sidebar section — the
|
||||
local theme (`site/themes/yggdrasil/partials/site-nav-sidebar.html`) filters
|
||||
the sidebar to the section containing the current page. Pages outside every
|
||||
category (landing page, `404`, standalone pages) fall back to the full
|
||||
sidebar.
|
||||
|
||||
## Deployment
|
||||
|
||||
`just build` produces a fully static site in `public/`: HTML pages with
|
||||
printable PDF twins, plus `sitemap.xml`, `robots.txt`, and `llms.txt`. The
|
||||
Gitea Actions workflow in
|
||||
`.gitea/workflows/build.yml` builds the site on every push with the same
|
||||
pinned toolchain and uploads `public/` as an artifact.
|
||||
|
||||
Pushes to `main` are also published: the `deploy` job force-pushes `public/`
|
||||
to the repo's `pages` branch using the automatic Actions token (no secrets to
|
||||
configure). A Gitea webhook on the repo then notifies the self-hosted
|
||||
[git-pages](https://codeberg.org/git-pages/git-pages) server, which clones
|
||||
the `pages` branch and serves the site. The push step is gated with
|
||||
`if: ${{ !env.ACT }}` so local `act` runs never publish, and
|
||||
`workflow_dispatch` enables manual publishes from the Gitea UI.
|
||||
- [OneDrive - Linux](/HES-SO/OneDrive.md)
|
||||
- [Teams - Linux](/HES-SO/Teams.md)
|
||||
|
After Width: | Height: | Size: 70 KiB |
@@ -0,0 +1,13 @@
|
||||
# 5G
|
||||
La 5G est l'évolution de le 4G LTE.
|
||||
|
||||
|
||||
## Fonctionnement
|
||||
|
||||
### 5G Standalone VS non-standalone
|
||||

|
||||
|
||||
|
||||
# Liens
|
||||
- [5G NR explications](https://ieeexplore.ieee.org/abstract/document/8879484https://ieeexplore.ieee.org/abstract/document/8879484)
|
||||
- [5G RAN](https://ieeexplore.ieee.org/document/9844937)
|
||||
@@ -0,0 +1,23 @@
|
||||
# C-V2X vs ITS-G5
|
||||
|
||||
# IEEE 802.11p
|
||||
Physical layer :
|
||||
|
||||
Il utilise l'[OFDM](/Wireless-Communication/Protocol/glossary.md#ofdm) pour varier de channel avec deux paramètres : le temps doublé qui implique
|
||||
que la fréquence est divisée de moitié.
|
||||
|
||||
Mac layer :
|
||||
|
||||
Il est basé sur un #OCB operation mode, où on utlisie pas les service d'authentification, d'association et de confidentialité de donnée.
|
||||
Mais, il est bien fait pour émettre de cours messages en broadcast et un au niveau de mobilité.
|
||||
|
||||
# C-V2X
|
||||

|
||||
|
||||
utilise du QPSK ou du 16-QAM
|
||||
|
||||
|
||||
# Conclusion
|
||||
Le C-V2X a de meilleure performance avec le même data rate que le [ITS-G5](/Wireless-Communication/Protocol/glossary.md#its-5g), il possède
|
||||
d'autres paramètres pouvant influencer positivement ses performances. Mais, dès qu'on augmente la densité d'utilisateurs et est supérieur à
|
||||
150 users/km2, le [ITS-G5](/Wireless-Communication/Protocol/glossary.md#its-5g) devient meilleur.
|
||||
@@ -0,0 +1 @@
|
||||
# DECT NR+
|
||||
@@ -0,0 +1,28 @@
|
||||
# IEEE 802.11
|
||||
[IEEE working group](https://www.ieee802.org/11/)
|
||||
|
||||
## 802.11p / ITS-G5
|
||||
|
||||
Cette technologie est la première standardisée pour la communication impliquant des véhicules.
|
||||
|
||||
##* Fonctionnement
|
||||
Elle utilise l'[OFDM](/Wireless-Communication/Protocol/glossary.md#ofdm) :
|
||||
|
||||
Channel Bandwith : 10MHz
|
||||
Modulation : 8
|
||||
|
||||
BitRate : 27Mb/s
|
||||
|
||||
[SCS](/Wireless-Communication/Protocol/glossary.md#scs) : 156.25 kHz
|
||||
|
||||
[CSMA/CA](/Wireless-Communication/Protocol/glossary.md#csmaca)
|
||||
|
||||
Designer pour peu de latence et une grande fiabilité, expressement pour une utilisation sécurisée
|
||||
sur route.
|
||||
|
||||
## IEEE 802.11BD / DOT11BD
|
||||
|
||||
|
||||
|
||||
liens :
|
||||
- [802.11p -> ITS-G5](https://ieeexplore.ieee.org/document/9734746)
|
||||
|
After Width: | Height: | Size: 342 KiB |
@@ -0,0 +1,11 @@
|
||||
<header><h1>
|
||||
Protocol de communication wireless
|
||||
</h1></header>
|
||||
|
||||
- [Glossaire](/Wireless-Communication/Protocol/glossary)
|
||||
- [5G](/Wireless-Communication/Protocol/5g)
|
||||
- [C-V2X vs ITS-G5](/Wireless-Communication/Protocol/C-V2X-vs-ITS-G5)
|
||||
- [IEEE 802.11](/Wireless-Communication/Protocol/IEEE%20802.11)
|
||||
- [V2X](/Wireless-Communication/Protocol/V2X)
|
||||
- [DECT NR+](/Wireless-Communication/Protocol/DECT-NR-+.md)
|
||||
- [Visible light communication](/Wireless-Communication/Protocol/Visible-light-communication.md)
|
||||
@@ -0,0 +1,41 @@
|
||||
# V2X
|
||||
Cette technologie utilise le concept de Sidelink
|
||||
|
||||
## C-V2X
|
||||
|
||||
### LTE-V2X
|
||||
Il est basé sur l'interface sideLink PC5 et la communication cellulaire.
|
||||
|
||||
Il support le broadcast, le groupcast et le unicast.
|
||||
|
||||
#### Mode 3
|
||||
Les [eNB](/Wireless-Communication/Protocol/glossary.md#enb) réservent et planifient les ressources
|
||||
radio pour les véhicules.
|
||||
|
||||
#### Mode 4
|
||||
Les véhicules réservent et planifient les ressource qu'ils ont besoin de manière autonome.
|
||||
|
||||
#### Conclusion
|
||||
Le mode 3 va dépendre de du réseau cellulaire, alors que le 4 est autonome.
|
||||
|
||||
### NR-V2X/5G-V2X
|
||||
|
||||
Il supporte le broadcast, le groupcast et le unicast.
|
||||
|
||||
Il permet d'avoir des sous fréquences porteuses en multiple de 15kHz qui favorise les transmissons
|
||||
critiques.
|
||||
|
||||
#### Mode 1
|
||||
|
||||
#### Mode 2
|
||||
|
||||
### Conclusion
|
||||

|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# Liens
|
||||
|
||||
- [LTE/NR-V2X](https://ieeexplore.ieee.org/document/9734746)
|
||||
@@ -0,0 +1,10 @@
|
||||
# Visible light communication
|
||||
|
||||
La technologie utilise de la lumière visible pour transmettre une information.
|
||||
|
||||
Il y a une application pour véhicule, mais elle s'applique particulièrement bien pour le voiture qui possèdent déjà de
|
||||
phares. Donc, je ne vois pas l'utilité de ce système pour les trains.
|
||||
|
||||
# Liens :
|
||||
- [applications](https://www.sciencedirect.com/science/article/pii/S2352864816300335)
|
||||
-
|
||||
@@ -0,0 +1,45 @@
|
||||
# Global glossary
|
||||
## V2X
|
||||
standard vehicle to vehicle/infrastructure communication systems from 3GPP
|
||||
|
||||
## ITS-5G
|
||||
standard vehicle to vehicle/infrastructure communication systems from IEEE
|
||||
|
||||
## CSMA/CA
|
||||
algo permettant de baisser la probabilité de collision entre packet
|
||||
|
||||
## OFDM
|
||||
Orthogonal Frequency Division Multiplexing
|
||||
|
||||
## OCB
|
||||
Outside the Context of a Basic Service Set
|
||||
|
||||
# C-V2X
|
||||
## RB
|
||||
Ressource Block
|
||||
|
||||
## TB
|
||||
Transport Block
|
||||
|
||||
## PSSCH
|
||||
Physical Sidelink Shared Channels
|
||||
[PSCCH](https://www.ni.com/docs/en-US/bundle/rfmx-waveform-creator/page/v2x-sidelink-communication.html#:~:text=Physical%20sidelink%20control%20channel%20(PSCCH,consecutive%20resource%20blocks%20(RBs).)
|
||||
|
||||
## SCI
|
||||
Sidelink Control Information pour contrôler les informations envoyées
|
||||
|
||||
## SB-SPS
|
||||
Sensing-Based Semi-Persistent Scheduling
|
||||
|
||||
## RC
|
||||
Reselection Counter, c'est ce qui va permettre d'éviter des collisions entre les différents véhicules utilisant les mêmes canaux
|
||||
|
||||
## MSC
|
||||
Modulation and Coding Scheme, détermine comment est transmis les datas (QPSK, ...), parmi la table suivante avec un RE (Resource Element)
|
||||
|
||||
## SCS
|
||||
SubCarrier Spacing, l'espacement entre les fréquences sous-porteuses d'un protocole
|
||||
|
||||
## eNB
|
||||
[Evolved Node B](https://www.artizanetworks.com/resources/tutorials/what_lteenb.html)
|
||||
|
||||
|
After Width: | Height: | Size: 28 KiB |
@@ -0,0 +1,18 @@
|
||||
# Wireless communication
|
||||
|
||||
## [Protocol](/Wireless-Communication/Protocol/)
|
||||
- [glossaire](/Wireless-Communication/Protocol/glossary)
|
||||
- [C-V2X vs ITS-G5](/Wireless-Communication/Protocol/C-V2X-vs-ITS-G5.md)
|
||||
- [IEEE 802.11](/Wireless-Communication/Protocol/IEEE%20802.11)
|
||||
- [V2X](/Wireless-Communication/Protocol/V2X)
|
||||
- [DECT NR+](/Wireless-Communication/Protocol/DECT-NR-+.md)
|
||||
- [Visible light communication](/Wireless-Communication/Protocol/Visible-light-communication.md)
|
||||
|
||||
|
||||
## [Train](/Wireless-Communication/Train/)
|
||||
- [Glossaire](/Wireless-Communication/Train/glossary.md)
|
||||
- [Channel model for performance evaluation](/Wireless-Communication/Train/Channel-model-for-performance-evaluation.md)
|
||||
- [FRMC - Projet 5GRail](/Wireless-Communication/Train/FRMC-Projet-5GRail.md)
|
||||
- [WTCMS](/Wireless-Communication/Train/WTCMS.md)
|
||||
|
||||
|
||||
@@ -0,0 +1,29 @@
|
||||
# Channel model for performance evaluation
|
||||
|
||||
## Tapped delay line
|
||||
|
||||

|
||||
|
||||
Il faut imaginer qu'après un élément de retard on vient rajouter un le signal retarder et on devrait obtenir en sortie une
|
||||
sorte d'escalier si on regarde assez petit. Cela, est ma réfléction en regardant le graphe au-dessus.
|
||||
|
||||
Il permet de simuler une communication sans file en simulant les pilonnes qui relayent le signal avec un retard
|
||||
s'additionnant au signal de base. Ensuite, il ne faut pas oublier qu'un effet doppler rentre en ligne de compte à chaque élément
|
||||
s'ajoutant sur le chemin de la transmission entre pilonnes.
|
||||
|
||||
## Environnement des chemins de fer
|
||||
Il faut prendre en compte la vitesse, le lieu (tunnel pour les métro, pilonne, ...)
|
||||
|
||||
On trouve 3 scénarios de communications :
|
||||
- Train-to-Ground (T2G)
|
||||
- Train-to-Train (T2T)
|
||||
- intra-train communications
|
||||
|
||||
## Conclusion
|
||||
Le papier montre qu'il existe plein de modèle de canaux, mais il ne prenne pas en compte tous les scénarios. Seulement les suivants :
|
||||
- Montagneux
|
||||
- Rural
|
||||
- Viaduque
|
||||
- de coupure
|
||||
|
||||
|
||||
@@ -0,0 +1,28 @@
|
||||
# FRMC Projet 5GRail
|
||||
Le document décrit comment le projet 5GRail a été prévu et simulé. Le but est de réaliser une simulation end-to-end pour
|
||||
plusieurs services utilisé par les trains (les fournisseurs). Le tout est séparé en plusieurs workpackage :
|
||||
|
||||
WP1 : dirigé par International Union of Railways (UIC)
|
||||
|
||||
WP2 : OBapp (on board applications) et TSapp (TrackSide application)
|
||||
|
||||
WP3 : fait au laboratoire nokia à Budapest
|
||||
- 5G/FRMCS-based [MCPTT](/Wireless-Communication/Train/glossary.md#mcptt) point-to-point and group voice communication realized by Siemens,
|
||||
- 5G/FRMCS-based Railway Emergency Call (REC) realized by Siemens,
|
||||
- [ETCS](/Wireless-Communication/Train/glossary.md#etcs) realized by CAF,
|
||||
- Train Control and Monitoring System (TCMS) realized by CAF,
|
||||
- Non-critical video application and CCTV archive transfer realized by Teleste.
|
||||
|
||||
WP4 : liaison des sites via VPN pour les testes
|
||||
|
||||
WP5 : testes réels
|
||||
|
||||
Fonctionnement :
|
||||
Le communication se fait au moyen de gateways qui permettent d'envoyer les données entre les trains et les stations de contrôle
|
||||
|
||||
Résultats des essais en laboratoires :
|
||||
- le premier appel end-to-end FRMCS
|
||||
- le management de la qualité des services en utilisant la méthode [DSCP](/Wireless-Communication/Train/glossary.md#DSCP)
|
||||
- les scénarios de changement de réseau 5G avec le [RV](/Wireless-Communication/Train/glossary.md#RV) activé
|
||||
- Préparations des activités pour les tests du package 5 c-à-d, **les effet de la vitesse sur les fréquence radios**
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
<header><h1>
|
||||
Protocol de communication wireless
|
||||
</h1></header>
|
||||
|
||||
- [Glossaire](/Wireless-Communication/Train/glossary)
|
||||
- [Channel model for performance evaluation](/Wireless-Communication/Train/Channel-model-for-performance-evaluation)
|
||||
- [FRMC - Projet 5GRail](/Wireless-Communication/Train/FRMC-Projet-5GRail)
|
||||
- [WTCMS](/Wireless-Communication/Train/WTCMS)
|
||||
@@ -0,0 +1,50 @@
|
||||
# Introduction
|
||||
Les trains utilise la technologie [GSM-R](/Wireless-Communication/Train/glossary.md#gsm-r) qui est
|
||||
l'ancien réseau mobile des trains. Dans notre cas, on veux utiliser la technologie
|
||||
[WTCMS](/Wireless-Communication/Train/glossary.md#wtcms).
|
||||
|
||||
# WTCMS
|
||||
Cette nouvelle technologie doit permettre d'enlever [ETB](/Wireless-Communication/Train/glossary.md#etb).
|
||||
|
||||
## Prérequis
|
||||
|
||||
1. la latence ne dois pas excéder 3 fois le temps de cycle du train
|
||||
2. le trains peut avoir 32 wagon avec une distance totale de 850m.
|
||||
3. Il doit être capable de d'interconnecter jsuqu'à 32 nodes
|
||||
4. Le changement dois être invisible pour les end-users
|
||||
|
||||
## Topologies alternatives
|
||||
### Variant 1 : Topologie linéaire
|
||||
Chacun des noeuds pour parler directement à ses voisins. Il peut communiquer avec le reste du réseau aussi en passant
|
||||
par ses voisins.
|
||||
|
||||
Cette manière permet d'atlerner les fréquences de communications entre chaque wagon. De cette manière, on utilise un moins
|
||||
large spectre dans les fréquences.
|
||||
|
||||
Son défaut est la latence total.
|
||||
Par contre, ce serait bien plus facile de mettre en place. Puisque le système est similaire à ce qui est déjà en place.
|
||||
Mais, la solution supprime pas tellement le réseau filaire actuel.
|
||||
|
||||
### Variant 2a : Topologie en Mesh
|
||||
Dans cette variante la topologie mesh permet de communiquer directement avec n'importe quel autre noeud du réseau. Mais,
|
||||
la latence dépend de la vitesse à laquelle chaque noeud peut réceptionner et transmettre.
|
||||
|
||||
### Variant 2b : Topologie en Mesh
|
||||
Dans cette variante, Il utilise la [Variant 1](#variant-1-topologie-linéaire) améliorée. C'est à dire, les noeuds peuvent
|
||||
communique transmette à leur voisin, s'ils ne peuvent pas atteindre le noeud cible.
|
||||
|
||||
### Conclusion
|
||||
La variant 1 est la plus simple à mettre en place. Mais, il garde la majorité des fils et garde une latence proportionnelle
|
||||
au chemin à parcourir du packet.
|
||||
|
||||
La variant 2a supprime le problème de délai de la variante 1, mais ce n'est pas réaliste de mettre une antenne pour émettre
|
||||
à 850m sur chaque wagon.
|
||||
|
||||
La variante 2b réduit la latence de la variante 1, en gardant des antennes qui emettent à 250m.
|
||||
|
||||
Finalement, la variante 2b est la plus réaliste à mettre en place.
|
||||
|
||||
## Comparaison de différent protocole
|
||||

|
||||
|
||||
|
||||
@@ -0,0 +1,101 @@
|
||||
# Global glossary
|
||||
|
||||
## CDL
|
||||
Cluster-Delay-Line
|
||||
|
||||
## CIR
|
||||
Channel Impulse Response
|
||||
|
||||
## LoS
|
||||
Line of Sight, le chemin direct entre un émetteur et un récepteur
|
||||
|
||||
## NLOS
|
||||
Non-Line-Of-Sight
|
||||
|
||||
## CRS
|
||||
cell-specific reference signal
|
||||
|
||||
## IP
|
||||
Intersection Point, le point d'intercection entre les rails et le le pilonne de transmission
|
||||
|
||||
## UL
|
||||
Uplink, c'est la cummunication entre le qqch au sol et le satellite
|
||||
|
||||
## DL
|
||||
Downlink, c'est la communication entre le satellite et le qqch au sol
|
||||
|
||||
## OAI
|
||||
Open Air Interface, c'est un projet open source pour les réseaux cellulaires RAN (Radio Access Network) et CN (Core Network)
|
||||
|
||||
## FRMCS
|
||||
Future Railway Mobile Communication System
|
||||
|
||||
## DSCP
|
||||
permet de classer le packet dans un réseau IP par ordre de priorité
|
||||
|
||||
## ETCS
|
||||
European Train Control System
|
||||
|
||||
## ATO
|
||||
Automatic Train Operation
|
||||
|
||||
## RV
|
||||
Remote Vision
|
||||
|
||||
## 5QI
|
||||
standard pour le 5G QoS identifiant, pour savoir la qualité du service
|
||||
|
||||
## MCPTT
|
||||
Mission Critical Push-to-Talk (utilisé pour la communication critique avec la pression sur une touche pour parler simplement et rapidement)
|
||||
|
||||
## PIS
|
||||
Passenger Information System
|
||||
|
||||
## RMR
|
||||
Railway Mobile Radio, réseau de communication pour les trains
|
||||
|
||||
## TDL
|
||||
Tapped-Delay-Line
|
||||
|
||||
## Jitter
|
||||
la variance de la latence entre le moment de la transmission et le moment de la réception
|
||||
|
||||
## RAT
|
||||
Radio Access Technology, la technologie utilisée pour accéder au réseau
|
||||
|
||||
## TCMS
|
||||
Train Control and Management System
|
||||
|
||||
## WTCMS
|
||||
Wireless Train Control and Management System
|
||||
|
||||
## GSM-R
|
||||
Global System for Mobile Communications - Railway, c'est un standard ancien de communication pour les trains
|
||||
|
||||
## WLTB
|
||||
Wireless Local Train Backbone, c'est un réseau de communication sans fil pour les trains
|
||||
|
||||
## ETB
|
||||
Ethernet Train Backbone, c'est un réseau de communication basé sur Ethernet pour les trains qui va être remplacer par le WLTB
|
||||
|
||||
## ETBN
|
||||
Ethernet Train Backbone Network, c'est un réseau de communication basé sur Ethernet pour les trains qui va être remplacer par le WLTB
|
||||
|
||||
## OMTS
|
||||
On-board Multimedia and Telematics
|
||||
|
||||
## COTS
|
||||
Commercial Off-The-Shelf, comprend l'ensemble des produits pouvant être utilisé achetable dans le commerce
|
||||
|
||||
## NG-TCN
|
||||
Next Generation Train Control Network,
|
||||
|
||||
## TSM
|
||||
Time Sensitve Networking, fonctionnalités qui servent à garantir les services dans le temps, déterministe
|
||||
|
||||
## Consist
|
||||
un ensemble de wagons qui sont attachés ensemble pour former par exemple une série de wagon 2ième classe ou autre chose
|
||||
|
||||
|
||||
|
||||
|
||||
|
After Width: | Height: | Size: 142 KiB |
|
After Width: | Height: | Size: 5.4 KiB |
@@ -0,0 +1,13 @@
|
||||
* [Protocol](/Wireless-Communication/Protocol/)
|
||||
* [glossaire](/Wireless-Communication/Protocol/glossary)
|
||||
* [C-V2X vs ITS-G5](/Wireless-Communication/Protocol/C-V2X-vs-ITS-G5)
|
||||
* [IEEE 802.11](/Wireless-Communication/Protocol/IEEE%20802.11)
|
||||
* [V2X](/Wireless-Communication/Protocol/V2X)
|
||||
* [DECT NR+](/Wireless-Communication/Protocol/DECT-NR-+.md)
|
||||
* [Visible light communication](/Wireless-Communication/Protocol/Visible-light-communication.md)
|
||||
|
||||
* [Train](/Wireless-Communication/Train/)
|
||||
* [glossaire](/Wireless-Communication/Train/glossary)
|
||||
* [Channel model for performance evaluation](/Wireless-Communication/Train/Channel-model-for-performance-evaluation)
|
||||
* [FRMC - Projet 5GRail](/Wireless-Communication/Train/FRMC-Projet-5GRail)
|
||||
* [WTCMS](/Wireless-Communication/Train/WTCMS)
|
||||
@@ -3,11 +3,13 @@
|
||||
* [SDi - Systèmes Distribués](/infotro/SDi/)
|
||||
* [Eln - Électronique](/infotro/Eln/)
|
||||
* [SEm - Systèmes Embarqués](/infotro/SEm/)
|
||||
* [MSE](/MSE/)
|
||||
* [SRE](/MSE/SRE/)
|
||||
* [Embed](/Embed/)
|
||||
* [STM32](/Embed/STM32/)
|
||||
* [nRF](/Embed/nRF/)
|
||||
* [HES-SO](/HES-SO/)
|
||||
* [OneDrive - Linux](/HES-SO/OneDrive.md)
|
||||
* [Teams - Linux](/HES-SO/Teams.md)
|
||||
* [Wireless Communication](/Wireless-Communication/)
|
||||
* [Protocol](/Wireless-Communication/Protocol/)
|
||||
* [Train](/Wireless-Communication/Train/)
|
||||
|
||||
@@ -189,9 +189,6 @@
|
||||
<link rel="stylesheet" href="//unpkg.com/docsify-accordion/src/style.css">
|
||||
<script src="//unpkg.com/docsify-accordion/src/index.js"></script>
|
||||
|
||||
<!----- Terminal ----->
|
||||
<script src="https://cdn.jsdelivr.net/npm/docsify-terminal-block@1.0.3"></script>
|
||||
|
||||
<!----- Last time updated ----->
|
||||
<script src="https://cdn.jsdelivr.net/npm/docsify-updated/src/time-updater.js"></script>
|
||||
|
||||