Compare commits
3 Commits
4ae2bac4ee
...
7cd8d2a48c
Author | SHA1 | Date |
---|---|---|
Harald Welte | 7cd8d2a48c | |
Harald Welte | 96f070b84e | |
Harald Welte | 848d961616 |
After Width: | Height: | Size: 41 KiB |
|
@ -0,0 +1,346 @@
|
||||||
|
Advanced SIM topics: ARA-M, SCP02, OTA, ISIM
|
||||||
|
============================================
|
||||||
|
:author: Harald Welte <laforge@gnumonks.org>
|
||||||
|
:copyright: 2022 by Harald Welte (License: CC-BY-SA)
|
||||||
|
:backend: slidy
|
||||||
|
:max-width: 45em
|
||||||
|
|
||||||
|
|
||||||
|
== Overview
|
||||||
|
|
||||||
|
* Administrative Commands
|
||||||
|
* ADF.ISIM
|
||||||
|
* DF.5GS
|
||||||
|
* ARA-M applet
|
||||||
|
* GlobalPlatform SCP02
|
||||||
|
* pySim-shell updates
|
||||||
|
|
||||||
|
== Recap: Some smartcard terminology
|
||||||
|
|
||||||
|
* card filesystem
|
||||||
|
** *MF* (Master File): The root directory
|
||||||
|
** *DF* (Dedicated File): A subdirectory
|
||||||
|
** *ADF* (Application Dedicated File): Directory of an application (like USIM, ISIM)
|
||||||
|
** *EF* (Entry File): A regulare file
|
||||||
|
*** *Transparent EF*: An unstructured file
|
||||||
|
*** *Linear Fixed EF*: An file consisting of fixed-length records
|
||||||
|
|
||||||
|
== specs vs. proprietary
|
||||||
|
|
||||||
|
* SIM cards are fully specified by a combination of ISU, ETSI and 3GPP specs
|
||||||
|
* this covers only the operation after the card has been issued, e.g.
|
||||||
|
** reading and writing files accessible without PIN auth, after PIN auth
|
||||||
|
** performing GSM authentication or UMTS AKA
|
||||||
|
* it does _not_ cover how the card is issued/provisioned
|
||||||
|
** secret key material (Ki / K / OP / OPc) is not readable from the card
|
||||||
|
** it is an implementation detail on how the card manufacturer writes those to the card
|
||||||
|
* this leads to the need for card-specific support / code in software like pySim
|
||||||
|
|
||||||
|
== Administrative Commands (TS 102 222)
|
||||||
|
|
||||||
|
* most well-known SIM/UICC commands relate to normal operation
|
||||||
|
** reflects what happens between phone (ME) and SIM
|
||||||
|
** SELECT, {READ,UPDATE} {BINARY,RECORD}, VERIFY CHV, ...
|
||||||
|
* there are also standardized _administrative_ commands
|
||||||
|
** intended for use by the operator / card issuer
|
||||||
|
** usually only work after authentication with ADM PIN or via secure channel
|
||||||
|
|
||||||
|
== Administrative Commands (TS 102 222)
|
||||||
|
|
||||||
|
* `CREATE FILE`
|
||||||
|
* `DELETE FILE`
|
||||||
|
* `DEACTIVATE FILE`
|
||||||
|
** temporary deactivation (cannot be selected anymore)
|
||||||
|
* `ACTIVATE FILE`
|
||||||
|
** reactivation of deactivated files
|
||||||
|
* `TERMINATE DF`
|
||||||
|
** DF can never be used again
|
||||||
|
* `TERMINATE EF`
|
||||||
|
** EF can never be used again
|
||||||
|
* `TERMINATE CARD USAGE`
|
||||||
|
** permanently bricks the card
|
||||||
|
|
||||||
|
== The ISIM application
|
||||||
|
|
||||||
|
The history:
|
||||||
|
|
||||||
|
* initial 2G SIM cards had `DF.GSM` + `DF.TELECOM`
|
||||||
|
* ETSI UICC was specified as application-independent card
|
||||||
|
* 3G/UMTS: 3GPP USIM application specified for UICC
|
||||||
|
* 4G/LTE: continues to use USIM
|
||||||
|
* IMS/VoLTE: optional ISIM application for UICC
|
||||||
|
|
||||||
|
== ISIM application: Entirely optional
|
||||||
|
|
||||||
|
* ISIM application is entirely optional
|
||||||
|
* IMS (VoLTE, VoWiFi) can be used with pure USIM
|
||||||
|
* without ISIM, default / fall-back mechanisms are used
|
||||||
|
** P-CSCF address
|
||||||
|
** Identities (IPUI derived from IMSI)
|
||||||
|
|
||||||
|
== ISIM application: Files in USIM or ISIM
|
||||||
|
|
||||||
|
Some files can either be in ADF.USIM **or** in ADF.ISIM
|
||||||
|
|
||||||
|
* cards without ISIM might have them in USIM
|
||||||
|
* cards with ISIM *must not* have them in USIM
|
||||||
|
|
||||||
|
Files:
|
||||||
|
|
||||||
|
* `EF.UICCIARI`
|
||||||
|
* `EF.FromPreferred`
|
||||||
|
* `EF.IMSConfigData`
|
||||||
|
* `EF.XCAPConfigData`
|
||||||
|
* `EF.MuDMiDConfigData`
|
||||||
|
|
||||||
|
== ISIM application: Separate authentication context
|
||||||
|
|
||||||
|
While IMS uses the same UMTS AKA Authentication Mechanism as 3G/4G systems,
|
||||||
|
the authentication context can be different:
|
||||||
|
|
||||||
|
* transport / access network (e.g. LTE) authenticates against USIM
|
||||||
|
* IMS core network (e.g. P-CSCF) authenticates against ISIM
|
||||||
|
|
||||||
|
At least in theory (and in practice with sysmoISIM-SJA2), one can configure
|
||||||
|
different key material and even choose different algorithms for the two
|
||||||
|
situations.
|
||||||
|
|
||||||
|
== ISIM application: Files in ADF.ISIM
|
||||||
|
|
||||||
|
image::adf_isim.png[align="center"]
|
||||||
|
|
||||||
|
== ISIM application: Files in ADF.ISIM
|
||||||
|
|
||||||
|
* `EV.IMPI` (IMS Private User Identity)
|
||||||
|
* `EF.DOMAIN` (Home Network Domain Name)
|
||||||
|
* `EF.IMPU` (IMS Public User Identity)
|
||||||
|
* `EF.AD` (Administrative Data)
|
||||||
|
* `EF.ARR` (Access Rule Reference)
|
||||||
|
* `EF.IST` (ISIM Service Table, like EF.UST for USIM)
|
||||||
|
* `EF.P-CSCF` (P-CSCF Address
|
||||||
|
* `EF.GBABP` (GBA Bootstrapping Parameters)
|
||||||
|
* `EF.NAFKCA` (NAF Key Centre Address)
|
||||||
|
* `EF.SMS / EF.SMSS / EF.SMSR / EF.SMSP` (SMS like in GSM/USIM)
|
||||||
|
* `EF.UICCIARI` (IMS Application Reference Identifier)
|
||||||
|
* `EF.FromPreferred`
|
||||||
|
* `EF.IMSConfigData`
|
||||||
|
* `EF.XCAPConfigData`
|
||||||
|
* `EF.WebRTCURI`
|
||||||
|
* `EF.MuDMiDConfigData`
|
||||||
|
|
||||||
|
|
||||||
|
== BER-TLV files (1/2)
|
||||||
|
|
||||||
|
* new file type ('structure') from existing known types
|
||||||
|
** transparent
|
||||||
|
** linear fixed
|
||||||
|
** cyclic
|
||||||
|
* BER-TLV files store data in BER-TLV format [surprise!]
|
||||||
|
* difference between storing BER-TLV in transparent file:
|
||||||
|
** read/write/delete only TLV for a certain specific tag
|
||||||
|
** no need to bother with padding
|
||||||
|
* supported from sysmoISIM-SJA2v2 onwards (IMSI ending in >= 50000)
|
||||||
|
|
||||||
|
== BER-TLV files (2/2)
|
||||||
|
|
||||||
|
* USIM Files specified as BER-TLV:
|
||||||
|
** `EF.URSP` (UE Route Selection Policies)
|
||||||
|
** `DF.GRAPHICS/EF.ICE_graphics` (?)
|
||||||
|
** `DF.MULTIMEDIA/EF.MML` (Multimedia Messages List)
|
||||||
|
** `DF.MULTIMEDIA/EF.MMDF` (Multimedia Messages Data File)
|
||||||
|
** `DF.MCS/EF.MCS_CONFIG` (Mission Critical Services)
|
||||||
|
** `DF.V2X/EF.V2X_CONFIG` (V2X configuration Data)
|
||||||
|
* ISIM Files specified as BER-TLV
|
||||||
|
** `EF.IMSConfigData` (IMS Configuration Data)
|
||||||
|
** `EF.MuDMiDConfigData` (Multi-Device / Multi-Identity Config)
|
||||||
|
|
||||||
|
|
||||||
|
== 5G SIM / DF.5GS
|
||||||
|
|
||||||
|
* 3GPP did not specify a new card application
|
||||||
|
* 5G/NR uses the same USIM as 4G/LTE and 3G/UMTS
|
||||||
|
* some optional additional files in ADF.USIM/DF.5GS
|
||||||
|
** together with their associated _services_ (122-135)
|
||||||
|
** `EF.5GS3GPPLOCI` (like EF.LOCI/3G and EF.EPSLOCI/4G)
|
||||||
|
** `EF.5GSN3GPPLOCI` (non-3GPP location information)
|
||||||
|
** `EF.5GS3GPPNSC` (NAS Security Context)
|
||||||
|
** `EF.5GAUTHKEYS` (K_SEAF / K_AUSF, like EF.KEYS/3G)
|
||||||
|
** `EF.UAC_AIC` (UAC Access Identities Configuration)
|
||||||
|
** `EF.SUCI_Calc_Info` (For SUCI computation in ME)
|
||||||
|
** `EF.OPL5G` (5GS Operator PLMN List)
|
||||||
|
** `EF.SUPI_NAI` (SUPI as Network Access Identifier)
|
||||||
|
** `EF.Routing_Indicator`
|
||||||
|
** `EF.URSP` (UE Route Selection Policies per PLMN)
|
||||||
|
** `EF.TN3GPPSNN` (Trusted non-3GPP Serving network names list)
|
||||||
|
|
||||||
|
== 5G SIM / Files in DF.5GS
|
||||||
|
|
||||||
|
image::df_5gs.png[align="center"]
|
||||||
|
|
||||||
|
== 5G SIM / Calculation of SUCI on SIM
|
||||||
|
|
||||||
|
* 5G introduces the optional SUCI security menchanism
|
||||||
|
** SUCI == Subscriber Concealed Identifier
|
||||||
|
* prevents IMSI (SUPI) transmission in plain-text
|
||||||
|
* two implementation options:
|
||||||
|
** SUCI computation on ME (phone) using key from SIM
|
||||||
|
** SUCI computation on SIM card
|
||||||
|
|
||||||
|
Some high-end cards (like eUICC) support SUCI calculation on the card.
|
||||||
|
|
||||||
|
|
||||||
|
== ARA-M and Android Carrier Privileges
|
||||||
|
|
||||||
|
* Android specific system to give apps more API access
|
||||||
|
** change carrier/operator settings like APN, Roaming, ...
|
||||||
|
** change IMS configuration for VoLTE / VoWiFi
|
||||||
|
** inject SMS into android from an app
|
||||||
|
* hash/cert of key used to sign app stored on SIM
|
||||||
|
* if Android detects apps signed with matching key, API access is enabled
|
||||||
|
* hash/cert is not stored as normal file in filesytem
|
||||||
|
* requires _Secure Element Access Control_ application on card
|
||||||
|
|
||||||
|
== ARA-M / Secure Element Access Control
|
||||||
|
|
||||||
|
image::ara-m-architecture.png[width=1000,align="center"]
|
||||||
|
|
||||||
|
== ARA-M in practice
|
||||||
|
|
||||||
|
* minimal open source ARA-M applet: https://github.com/bertrandmartel/aram-applet
|
||||||
|
* pre-installed on sysmoISIM-SJA2
|
||||||
|
* pySim-shell has support for adding/deleting rules (see user manual)
|
||||||
|
* see https://github.com/herlesupreeth/CoIMS_Wiki for more information
|
||||||
|
|
||||||
|
== pySim-shell updates since April 2021
|
||||||
|
|
||||||
|
* commands
|
||||||
|
** more decoders for more files
|
||||||
|
** TS 102 222 administrative commands
|
||||||
|
** `ust_service_check`
|
||||||
|
** `apdu` command
|
||||||
|
** `export --json`
|
||||||
|
* encoders/decoers
|
||||||
|
** TLV definitions for IMS, XCAP and MudMid
|
||||||
|
** FCP in `export`
|
||||||
|
* BER-TLV file support
|
||||||
|
* ARA-M support
|
||||||
|
* support for generic, non-sysmocom cards
|
||||||
|
* WIP
|
||||||
|
** basic GlobalPlatform commands
|
||||||
|
** `decode_hex` command
|
||||||
|
|
||||||
|
|
||||||
|
== GlobalPlatform
|
||||||
|
|
||||||
|
* GlobalPlatform specifies the Javacard universe
|
||||||
|
* SIM cards are not required to be Java cards, but in practice they mostly are
|
||||||
|
** ... and they mostly only implement ancient GlobalPlatform versions
|
||||||
|
* specifies how to install/remove/lock/unlock applets
|
||||||
|
* specifies transport layer security protocols (SCP02, SCP03)
|
||||||
|
|
||||||
|
== GlobalPlatform APDU commands
|
||||||
|
|
||||||
|
* Key Management
|
||||||
|
** `PUT KEY`
|
||||||
|
** `DELETE KEY`
|
||||||
|
* Data
|
||||||
|
** `GET DATA`
|
||||||
|
** `STORE DATA`
|
||||||
|
* Application Locking/Unlocking
|
||||||
|
** `GET STATUS`
|
||||||
|
** `SET STATUS`
|
||||||
|
* Installation / Deletion (Executables, Applets)
|
||||||
|
** `INSTALL`
|
||||||
|
** `DELETE`
|
||||||
|
|
||||||
|
== GlobalPlatform INSTALL / DELETE flavours
|
||||||
|
|
||||||
|
* `INSTALL`
|
||||||
|
** `INSTALL [for load]`
|
||||||
|
** `INSTALL [for install]`
|
||||||
|
** `INSTALL [for load, install and make selectable]`
|
||||||
|
** `INSTALL [for install and make selectable]`
|
||||||
|
** `INSTALL [for make selectable]`
|
||||||
|
** `INSTALL [for extradition]`
|
||||||
|
** `INSTALL [for registry update]`
|
||||||
|
** `INSTALL [for personalization]`
|
||||||
|
* `DELETE`
|
||||||
|
** Executable Load File
|
||||||
|
** Executable Load File and related Applications
|
||||||
|
** Application
|
||||||
|
|
||||||
|
== GlobalPlatform SCP02 initiation
|
||||||
|
|
||||||
|
* mutual authentication between card and external software
|
||||||
|
** contains random factor from both sides
|
||||||
|
** generates session keys
|
||||||
|
* transport-level security established ('secure messaging')
|
||||||
|
* protected APDUs between on-card software and off-card software
|
||||||
|
|
||||||
|
image::scp02-flow.png[align="center"]
|
||||||
|
|
||||||
|
== GlobalPlatform SCP02 APDU commands
|
||||||
|
|
||||||
|
* `INITIALIZE UPDATE`
|
||||||
|
* `EXTERNAL AUTHENTICATE`
|
||||||
|
* `BEGIN R-MAC SESSION`
|
||||||
|
* `END R-MAC SESSION`
|
||||||
|
|
||||||
|
== C-MAC
|
||||||
|
|
||||||
|
* C-MAC (Command Message Authentication Code)
|
||||||
|
** either on unmodified APDU or modified APDU
|
||||||
|
|
||||||
|
image::scp02_cmac_modified.png[align="center"]
|
||||||
|
|
||||||
|
== R-MAC
|
||||||
|
|
||||||
|
optional MAC on responses generated by card
|
||||||
|
|
||||||
|
image::scp02_rmac.png[align="center"]
|
||||||
|
|
||||||
|
|
||||||
|
== Data Field Encryption
|
||||||
|
|
||||||
|
optional confidentiality of data field of APDUs
|
||||||
|
|
||||||
|
image::scp02_data_field_encryption.png[align="center"]
|
||||||
|
|
||||||
|
|
||||||
|
== OTA (Over The Air)
|
||||||
|
|
||||||
|
* Mechanism how some software in operator core can talk to SIM in the field
|
||||||
|
* traverses the entire 3GPP Core and Radio Access Network, hence _over the air_.
|
||||||
|
|
||||||
|
image::ota_overview.png[width=1000,align="center"]
|
||||||
|
|
||||||
|
== OTA transport mechanisms
|
||||||
|
|
||||||
|
* SMS-PP (SMS as you know it)
|
||||||
|
* SMS-CB (Cell Broadcast)
|
||||||
|
** would require shared keys, bad idea
|
||||||
|
* USSD
|
||||||
|
** faster, more responsive than SMS
|
||||||
|
* BIP (Bearer Independent Protocol)
|
||||||
|
** CSD, GPRS, Bluetooth, IrDA
|
||||||
|
* HTTP over TLS-PSK on the card (!)
|
||||||
|
** Amendmend B GlobalPlatform Card Sepc v2.2
|
||||||
|
|
||||||
|
== Further Reading
|
||||||
|
|
||||||
|
* https://git.osmocom.org/pysim/about/[pySim source code / git repository]
|
||||||
|
* https://media.ccc.de/v/36c3-10737-sim_card_technology_from_a-z[Video of talk "SIM card technology from A-Z"]
|
||||||
|
* Specs
|
||||||
|
** ETSI TS 102 221 (UICC)
|
||||||
|
** ETSI TS 102 222 (Administrative Commands)
|
||||||
|
** ETSI TS 102 223 (Bearer Independent Protocol)
|
||||||
|
** ETSI TS 102 225 (Secured Packets for OTA)
|
||||||
|
** 3GPP TS 31.102 (USIM)
|
||||||
|
** 3GPP TS 31.103 (ISIM)
|
||||||
|
** GlobalPlatform Card Specification 2.2.1
|
||||||
|
** GlobalPlatform Secure Element Access Control v1.0
|
||||||
|
|
||||||
|
|
||||||
|
== EOF
|
||||||
|
|
||||||
|
End of File
|
After Width: | Height: | Size: 143 KiB |
After Width: | Height: | Size: 32 KiB |
After Width: | Height: | Size: 51 KiB |
After Width: | Height: | Size: 68 KiB |
After Width: | Height: | Size: 68 KiB |
After Width: | Height: | Size: 72 KiB |
After Width: | Height: | Size: 44 KiB |
After Width: | Height: | Size: 64 KiB |
After Width: | Height: | Size: 1.0 MiB |
|
@ -0,0 +1,386 @@
|
||||||
|
OCTOI - Osmocom Community TDM over IP
|
||||||
|
=====================================
|
||||||
|
:author: Harald Welte <laforge@gnumonks.org>
|
||||||
|
:copyright: 2022 by Harald Welte (License: CC-BY-SA)
|
||||||
|
:backend: slidy
|
||||||
|
:max-width: 45em
|
||||||
|
|
||||||
|
|
||||||
|
== Overview
|
||||||
|
|
||||||
|
* WTF? Why?
|
||||||
|
* History: TDM networks
|
||||||
|
* existing TDMoIP technology
|
||||||
|
* OCTOI Protocol
|
||||||
|
* OCTOI Software
|
||||||
|
* Current OCTOI Network
|
||||||
|
* WIP / Future Plans
|
||||||
|
|
||||||
|
== WTF is this all about?
|
||||||
|
|
||||||
|
* enable people to run legacy WAN equipment
|
||||||
|
** Modems, Phones (analog, ISDN), PBXs
|
||||||
|
** ISDN-Adapters
|
||||||
|
** Frame Relay / HDLC / X.25 / routers
|
||||||
|
* in a distributed fashion, over the internet
|
||||||
|
* allow to run retronetworking tech from mid-1980s to about 2010 at a time where the related transport
|
||||||
|
services are no longer available from public telephone operators / carriers
|
||||||
|
|
||||||
|
// ***********************************************************************
|
||||||
|
// History: TDM networks
|
||||||
|
// ***********************************************************************
|
||||||
|
|
||||||
|
== History: analog telephone networks
|
||||||
|
|
||||||
|
public switched telephone network (PSTN)
|
||||||
|
|
||||||
|
* traditionally used only analog lines
|
||||||
|
** base band on twisted pair on last mile
|
||||||
|
** base band on twisted pair between exchanges nearby
|
||||||
|
** analog modulated carrier wave on coaxial cables or microwave links for long distance
|
||||||
|
|
||||||
|
== History: TDM networks + ISDN
|
||||||
|
|
||||||
|
* at some point (1970s?), digital PCM technology was introduced between exchanges
|
||||||
|
** initially PDH, later SDH (which can transport PDH)
|
||||||
|
** see https://media.ccc.de/v/osmodevcall-20211112-laforge-tdm[OsmoDevCall on TDM/PDH/SDH]
|
||||||
|
* external interfaces, particularly to subscriber, still analog until mid-1980s
|
||||||
|
* ISDN changed that: Introduced digital subscriber lines
|
||||||
|
** Basic Rate ISDN (BRI): 2x B, 1x D-Channel
|
||||||
|
** Primary Rate ISDN (PRI): 30x B, 1x D-Channel
|
||||||
|
|
||||||
|
== Present: TDM networks mostly dead
|
||||||
|
|
||||||
|
* Telcos have meanwhile mostly migrated to All-IP telephony
|
||||||
|
* PDH/SDH networks mostly shut down, occasionally still in operation for legacy customers or some internal
|
||||||
|
legacy services. Not actively sold anymore.
|
||||||
|
* You cannot get a real PRI line anymore to connect your ISDN PBX or your Cisco router
|
||||||
|
* Idea: Create community network of people who want to play with ISDN / TDM stuff
|
||||||
|
* Naive approach: Use existing, off-the-shelf TDMoIP devices
|
||||||
|
|
||||||
|
|
||||||
|
== Wanted: TDMoIP network
|
||||||
|
|
||||||
|
[graphviz]
|
||||||
|
----
|
||||||
|
graph G {
|
||||||
|
hub [shape=box, label="TDMoIP hub\ncross-connect\nin public internet"];
|
||||||
|
subgraph cluster_1 {
|
||||||
|
label="Hobbyist A";
|
||||||
|
ad1 [label="Access Device\n"];
|
||||||
|
pbx1 [label="PBX"];
|
||||||
|
phone1a [label="Phone"];
|
||||||
|
modem1b [label="Modem"];
|
||||||
|
ta1c [label="ISDN TA"];
|
||||||
|
pbx1 -- ad1 [label="E1"];
|
||||||
|
phone1a -- pbx1 [label="POTS"];
|
||||||
|
modem1b -- pbx1 [label="POTS"];
|
||||||
|
ta1c -- pbx1 [label="ISDN-BRI"];
|
||||||
|
}
|
||||||
|
subgraph cluster_2 {
|
||||||
|
label="Hobbyist B";
|
||||||
|
ad2 [label="Access Device\n"];
|
||||||
|
pbx2 [label="PBX"];
|
||||||
|
phone2a [label="Phone"];
|
||||||
|
modem2b [label="Modem"];
|
||||||
|
ta2c [label="ISDN TA"];
|
||||||
|
pbx2 -- ad2 [label="E1"];
|
||||||
|
phone2a -- pbx2 [label="POTS"];
|
||||||
|
modem2b -- pbx2 [label="POTS"];
|
||||||
|
ta2c -- pbx2 [label="ISDN-BRI"];
|
||||||
|
}
|
||||||
|
subgraph cluster_3 {
|
||||||
|
label="Hobbyist C";
|
||||||
|
ad3 [label="Access Device\n"];
|
||||||
|
pbx3 [label="PBX"];
|
||||||
|
phone3a [label="Phone"];
|
||||||
|
modem3b [label="Modem"];
|
||||||
|
ta3c [label="ISDN TA"];
|
||||||
|
pbx3 -- ad3 [label="E1"];
|
||||||
|
phone3a -- pbx3 [label="POTS"];
|
||||||
|
modem3b -- pbx3 [label="POTS"];
|
||||||
|
ta3c -- pbx3 [label="ISDN-BRI"];
|
||||||
|
}
|
||||||
|
ad1 -- hub [label="TDMoIP\nInternet"];
|
||||||
|
ad2 -- hub [label="TDMoIP\nInternet"];
|
||||||
|
ad3 -- hub [label="TDMoIP\nInternet"];
|
||||||
|
}
|
||||||
|
----
|
||||||
|
|
||||||
|
// ***********************************************************************
|
||||||
|
// Existing TDMoIP technology
|
||||||
|
// ***********************************************************************
|
||||||
|
|
||||||
|
== Existing TDMoIP: SAToP / CESoPSN
|
||||||
|
|
||||||
|
So we just get some of these and all is good?
|
||||||
|
|
||||||
|
image::RAD_IPmux-1_front.jpg[width=1200,align="center"]
|
||||||
|
|
||||||
|
== Existing TDMoIP: SAToP / CESoPSN
|
||||||
|
|
||||||
|
Examples for _transparent_ TDMoIP technologies
|
||||||
|
|
||||||
|
* SAToP (Structure Agnostic TDM over IP)
|
||||||
|
** RFC 4553
|
||||||
|
* CESoPSN (Circuit Emulation Service over Packet Switched Network)
|
||||||
|
** RFC 5086
|
||||||
|
* transport of raw E1 frames over MPLS or UDP
|
||||||
|
* designed for use in LAN or carrier backbone networks
|
||||||
|
* waste a lot of bandwidth, even if TDM circuits are completely idle
|
||||||
|
** > 2Mbps plus header/packet overhead, bi-directional
|
||||||
|
* typically no support for dynamic IP addresses
|
||||||
|
|
||||||
|
== Existing TDMoIP: SIGTRAN IUA, EL2TPD
|
||||||
|
|
||||||
|
Examples for _non-transparent_ TDMoIP technologies
|
||||||
|
|
||||||
|
* SIGTRAN IUA (ISDN User Adaptation)
|
||||||
|
** RFC 3057
|
||||||
|
** works only for ISDN BRI/PRI with Q.921 as Layer 2 on signaling channel
|
||||||
|
** uses SCTP as transport (might not pass all middleboxes in public internet)
|
||||||
|
** no specification how the B-channels are handled, pure signaling solution
|
||||||
|
* Ericsson L2TP / PacketAbis over IP
|
||||||
|
** proprietary, but FOSS implementation in @osmo-el2tpd@
|
||||||
|
** makes specific assumption of use of E1 as Ericsson Abis (GSM BTS back-haul)
|
||||||
|
|
||||||
|
// ***********************************************************************
|
||||||
|
// OCTOI TDMoIP protocol
|
||||||
|
// ***********************************************************************
|
||||||
|
|
||||||
|
== The case for a new TDMoIP protocol
|
||||||
|
|
||||||
|
There's room for a new protocol based on the following goals:
|
||||||
|
|
||||||
|
* *transparent*. Should work for ISDN and other use cases (Frame Relay, Abis, SS7, ATM, ...)
|
||||||
|
* *efficient*. Should not waste a lot of bandwidth on an otherwise idle/unused link
|
||||||
|
* *dynamic IP*. End-user internet access normally has dynamic IP addresses
|
||||||
|
* *nat friendly*. Should work through any number of NATs and CG-NAT without special ALG/helper
|
||||||
|
* *IPv6 support*. Should support IPv6 just like IPv4
|
||||||
|
* *authentication*. Should have built-in mutual authentication
|
||||||
|
|
||||||
|
== OCTOI Protocol: Bandwidth
|
||||||
|
|
||||||
|
* Timeslot Suppression
|
||||||
|
** Transmitter has history of 1 TDM frame
|
||||||
|
** Before Tx, to-be-transmitted frame is compared with last frame
|
||||||
|
** only those timeslots with value != that of last frame are transmitted
|
||||||
|
* Batching
|
||||||
|
** Batch 32 (up to 40) E1 frames per UDP packet
|
||||||
|
*** 8000 frames/s / 32 => 250 packets/s
|
||||||
|
|
||||||
|
Result: About 70 kbit/s (including UDP + IPv4 overhead) on idle E1 link
|
||||||
|
|
||||||
|
== OCTOI Protocol: dynamic IP / NAT-friendly
|
||||||
|
|
||||||
|
* Classic client/server approach
|
||||||
|
* Server currently requires fixed IP (no STUN/ICE/...)
|
||||||
|
* Clients can have dynamic IPs
|
||||||
|
* All messages (control plane + TDM user plan) in one UDP flow
|
||||||
|
|
||||||
|
// ***********************************************************************
|
||||||
|
// OCTOI Software
|
||||||
|
// ***********************************************************************
|
||||||
|
|
||||||
|
== E1oIP: osmo-e1d + icE1usb
|
||||||
|
|
||||||
|
* osmo-e1d was the first (libusb, userspace) driver for the icE1usb hardware
|
||||||
|
* traditionally, it sits between icE1usb hardware and applications using E1 like osmo-bsc
|
||||||
|
* instead of a local application, it can now interface icE1usb to OCTOI
|
||||||
|
** `octoi-server` mode
|
||||||
|
** `octoi-client` mode
|
||||||
|
|
||||||
|
First 4 OCTOI users were connected to the hub that way
|
||||||
|
|
||||||
|
[graphviz]
|
||||||
|
----
|
||||||
|
graph {
|
||||||
|
rankdir=LR;
|
||||||
|
subgraph cluster_L {
|
||||||
|
label="Site L";
|
||||||
|
PBX_L [label="PBX"];
|
||||||
|
icE1usb_L [label="icE1usb"];
|
||||||
|
GW_L [label="GW L"];
|
||||||
|
PBX_L -- icE1usb_L [label="E1"];
|
||||||
|
icE1usb_L -- GW_L [label="USB"];
|
||||||
|
}
|
||||||
|
subgraph cluster_R {
|
||||||
|
label="Site R";
|
||||||
|
PBX_R [label="PBX"];
|
||||||
|
icE1usb_R [label="icE1usb"];
|
||||||
|
GW_R [label="GW R"];
|
||||||
|
PBX_R -- icE1usb_R [label="E1"];
|
||||||
|
icE1usb_R -- GW_R [label="USB"];
|
||||||
|
}
|
||||||
|
Internet;
|
||||||
|
GW_L -- Internet [label="IP"];
|
||||||
|
GW_R -- Internet [label="IP"];
|
||||||
|
}
|
||||||
|
----
|
||||||
|
|
||||||
|
== E1oIP: osmo-e1d + dahdi-trunkdev
|
||||||
|
|
||||||
|
* having one icE1usb per peer/user doesn't scale at the hub
|
||||||
|
* this triggered the development of `dahdi-trunkdev`
|
||||||
|
** virtual E1 _span_ for DAHDI without any real hardware
|
||||||
|
** simply provides stream of E1 frames on a character-device
|
||||||
|
** can be used to implement any virtual TDM interface/protocol
|
||||||
|
* osmo-e1d was extended to open dahdi-trunkdev instead of icE1usb
|
||||||
|
|
||||||
|
Next 4 OCTOI users were connected to the hub that way; will become standard for all users
|
||||||
|
|
||||||
|
[graphviz]
|
||||||
|
----
|
||||||
|
graph {
|
||||||
|
rankdir=LR;
|
||||||
|
subgraph cluster_L {
|
||||||
|
label="Site L";
|
||||||
|
PBX_L [label="PBX"];
|
||||||
|
icE1usb_L [label="icE1usb"];
|
||||||
|
GW_L [label="GW L"];
|
||||||
|
PBX_L -- icE1usb_L [label="E1"];
|
||||||
|
icE1usb_L -- GW_L [label="USB"];
|
||||||
|
}
|
||||||
|
subgraph cluster_R {
|
||||||
|
label="Site R";
|
||||||
|
PBX_R [label="PBX\n(Virtual DAHDI)"];
|
||||||
|
}
|
||||||
|
Internet;
|
||||||
|
GW_L -- Internet [label="IP"];
|
||||||
|
PBX_R -- Internet [label="IP"];
|
||||||
|
}
|
||||||
|
----
|
||||||
|
|
||||||
|
// ***********************************************************************
|
||||||
|
// Current OCTOI Network
|
||||||
|
// ***********************************************************************
|
||||||
|
|
||||||
|
== Current OCTOI network hub
|
||||||
|
|
||||||
|
* Debian 11 with `dahdi-trunkdev`, `osmo-e1d` and `yate`
|
||||||
|
* since physical machine died recently: migrated into qemu-kvm
|
||||||
|
** SRV-IO for NIC, USB Host Controller and DADHI card (TE820)
|
||||||
|
* TE820 8-port E1 card, attaches to
|
||||||
|
** LaF0rge's local PBX (Auerswald COMmander 2 basic)
|
||||||
|
** Livingston PortMaster 3 RAS
|
||||||
|
** 4x icE1usb
|
||||||
|
** Cisco AS5400
|
||||||
|
|
||||||
|
== Current OCTOI participants
|
||||||
|
|
||||||
|
The hub currently has the following clients / participants:
|
||||||
|
|
||||||
|
* using icE1usb at hub side
|
||||||
|
** manawyrm
|
||||||
|
** gruetzkopf
|
||||||
|
** roox
|
||||||
|
** cquirin
|
||||||
|
* using `dahdi-trunkdev` at hub side
|
||||||
|
** drdeke
|
||||||
|
** tmwawpl
|
||||||
|
** tom/sirtux
|
||||||
|
** tnt
|
||||||
|
|
||||||
|
== Current OCTOI services
|
||||||
|
|
||||||
|
* E1 / TDM as "transport" layer
|
||||||
|
* ISDN network as "routing" layer
|
||||||
|
** hub simulates the network / central office / switch side
|
||||||
|
** client devices implement the "user" side, just like when attaching to ISDN/PSTN
|
||||||
|
* Services on top of ISDN
|
||||||
|
** Audio Telephony
|
||||||
|
** Video Telephony (T-View 100 / H.320)
|
||||||
|
** ISDN Data Calls
|
||||||
|
** Analog Modem Calls
|
||||||
|
|
||||||
|
== OCTOI ISDN / Modem calls
|
||||||
|
|
||||||
|
* hub currently has a https://osmocom.org/projects/retronetworking/wiki/Livingston_Portmaster_3[Livingston Portmaster 3] RAS
|
||||||
|
** up to 30 ISDN data or analog modem calls (up to V.90)
|
||||||
|
* services can be created in RADIUS, identified by Called Party Number
|
||||||
|
** PPP dial-up locally terminated
|
||||||
|
** PPP dial-up with forwarding of data via L2TP to remote LAC
|
||||||
|
** telnet or TCP clear forwarding to remote BBSs
|
||||||
|
* Cisco AS5400 with much higher capacity is waiting to be provisioned
|
||||||
|
|
||||||
|
== Challenges: Clocking
|
||||||
|
|
||||||
|
* TDM networks need a stable bitclock at all parts of the network
|
||||||
|
* everyone must transmit and receive at the same rate of bits / frames
|
||||||
|
* we use GPS disciplined oscillators (GPS-DO) to ensure same clock everywhere
|
||||||
|
** this avoids overruns / underruns resulting in cycle slips that would create phase discontinuity for
|
||||||
|
any modem signals carried over the network
|
||||||
|
|
||||||
|
== Challenges: Packet Re-ordering
|
||||||
|
|
||||||
|
* It seems like particularly on DOCSIS there is quite a bit of UDP packet re-ordering
|
||||||
|
* Initially, osmo-e1d used a FIFO and dropped all out-of-order packets
|
||||||
|
* later, we introduced a RIFO (Random In, First Out) to support re-ordering without loss
|
||||||
|
|
||||||
|
== Challenges: Packet Loss
|
||||||
|
|
||||||
|
* There is quite a bit of packet loss on the public internet
|
||||||
|
* People probably don't generally notice much, as most services use TCP or retransmit UDP
|
||||||
|
* Surprisingly, I couldn't find any comprehensive studies / research papers on packet loss behaviour of
|
||||||
|
consumer internet that are less than 10 years old?
|
||||||
|
* Right now we just accept it exists
|
||||||
|
* Some early thoughts and experiments on FEC (Forward Error Correction)
|
||||||
|
|
||||||
|
== Challenges: Latency
|
||||||
|
|
||||||
|
* intercontinental public IP can easily reach >= 200ms RTT
|
||||||
|
* ISDN timers in Q.921 and Q.931 are luckily working just fine over that kind of RTT
|
||||||
|
* some suspicion that the high latency might have negative impact on Fax (T.30 timers) and modems (buffer
|
||||||
|
sizes). I'm personally not yet convinced it is really an issue.
|
||||||
|
|
||||||
|
|
||||||
|
// ***********************************************************************
|
||||||
|
// Future Plans
|
||||||
|
// ***********************************************************************
|
||||||
|
|
||||||
|
== Future Plans
|
||||||
|
|
||||||
|
* migrate OCTOI hub to co-location / data centre
|
||||||
|
** higher capacity, better reliability, less packet loss
|
||||||
|
* ISDN BRI (S/T) access to OCTOI network
|
||||||
|
** more end-user friendly; many people have S0 equipment and no E1/S2M PBX at home
|
||||||
|
* Frame Relay switch / hub
|
||||||
|
** second, additional service, completely independent of the current ISDN service
|
||||||
|
** initial testing has confirmed HDLC / FR over OCTOI works without problems
|
||||||
|
* exhibits at hacker and vintage computing events
|
||||||
|
|
||||||
|
== ISDN BRI (S/T) access to OCTOI
|
||||||
|
|
||||||
|
* BRI (ISDN basic rate aka "S/T" aka "S0") support in OCTOI protocol
|
||||||
|
* BRI hardware with 2x S/T interface and GPS-DO
|
||||||
|
** unlike icE1usb: Ethernet/IP support, not USB
|
||||||
|
** complete _appliance_ for OCTOI client mode: no need for computer
|
||||||
|
** Status: design of first break-out / evaluation board for ISDN BRI side complete
|
||||||
|
** Software not even started yet. Idea is to use Nuttx on Atmel SAMV71
|
||||||
|
|
||||||
|
== Longer-Term Future Plans
|
||||||
|
|
||||||
|
* improve FOSS soft-modem situation (linmodem, spandsp)
|
||||||
|
* investigate somewhat limited V.90 performance so far
|
||||||
|
* investigate somewhat limited throughput of PM3 in tcp-clear/telnet-forwarding
|
||||||
|
* support for other Q.931 dialects than DSS1 (like 1TR6 or even NI1)
|
||||||
|
* X.25 / X.31 support
|
||||||
|
|
||||||
|
== Thanks
|
||||||
|
|
||||||
|
Thanks to
|
||||||
|
|
||||||
|
* Sylvain "tnt" Munaut for icE1usb and all his help
|
||||||
|
* All of the early OCTOI network participants manawyrm, gruetzkopf, roox, DrDeke, tmwawpl, cquirin
|
||||||
|
|
||||||
|
== Further Reading
|
||||||
|
|
||||||
|
* https://osmocom.org/projects/octoi/wiki[OCTOI Project Homepage/Wiki]
|
||||||
|
* https://osmocom.org/projects/octoi/wiki/Proposed_efficient_TDMoIP[OCTOI Protocol Description]
|
||||||
|
* https://osmocom.org/projects/retronetworking/wiki[Retronetworking Wiki]
|
||||||
|
* https://osmocom.org/projects/osmo-e1d/wiki/Wiki[osmo-e1d software]
|
||||||
|
* https://osmocom.org/projects/octoi/wiki/Proposed_efficient_TDMoIP[icE1usb hardware]
|
||||||
|
|
||||||
|
== EOF
|
||||||
|
|
||||||
|
End of File
|