retronetcall / B-channel protocols

2022/retronetcall-v110_v120_x75_h221/v110_v120_x75_h221.adoc

@@ -0,0 +1,266 @@
+ISDN B-Channel protocols: V.110, V.120, X.75, H.221
+===================================================
+:author:	Harald Welte <laforge@gnumonks.org>
+:copyright:	2022 by Harald Welte (License: CC-BY-SA)
+:backend:	slidy
+:max-width:	45em
+
+
+== Overview
+
+* quick recap on D-channel
+* overview of B-channel classes/formats
+* V.110
+* HDLC/syncPPP
+* V.120
+* X.75
+* H.221
+
+== ISDN D-channel protocols
+
+* many have seen ISDN D-channel protocol traces
+** Q.921 (LAPD) as Layer 2
+** Q.931 as Layer 3 for call control
+* several FOSS implementations around
+* quite a bit of literature
+* protocol decoders in wireshark
+
+== ISDN B-channel protocols: Why?
+
+* we had modems to transmit serial data over analog
+* now that we have a digital ISDN B-channel, why are protocols needed?
+* _serial data_ is traditionally not just a stream of bytes, but
+** modem control signals (CD, DSR/DTR, RTS/CTS, ...)
+** variable number of data bits, stop bits, parity
+** ... and what about the break condition?
+
+== ISDN B-channel protocols
+
+* transport of
+* interoperability with legacy data (modem, *V-series*) applications
+** V.110
+** V.120
+** X.75
+* video telephony
+** H.221
+* IP or other network traffic
+** bit-synchronous HDLC
+** octet-synchronous HDLC
+
+
+
+== ISDN Terminal Adapters: Interfaces
+
+* R interface (V-series / "RS-232")
+* S interface (S0 in Germany)
+* U interface (Uk0 in Germany)
+
+== V.110
+
+* rate adaptation between classic serial modem rates and ISDN
+* support synchronous and asynchronous user communications
+
+image::v120_figure1_connection_services.png[]
+
+== V.110 for synchronous users
+
+* bit-rates 600, 1200, 2400, 4800, 7200, 9600, 12000, 14400, 19200, 24000, 28800, 38400
+* two rate adaptation functions
+** RA1
+** RA2
+
+image::v110_figure1.png[width=1200,align="center"]
+
+== V.110 RA1 generic frame structure
+
+image::v110_table2_frame_structure.png[]
+
+* 17bit sync pattern
+* 48 D-bits (user data)
+* 7 E-bits (encode frame format/rate)
+* 8 S/X-bits (RTS/CTS/DTR/CD/... status lines)
+
+== V.110 RA1 specific frame structure
+
+image::v110_tables6abcd_frames.png[width=1200,align="center"]
+
+* same as generic frame structure
+* rate specific D-bit repetition
+* rate specific E1/E2/E3 bit
+
+== V.110 RA0 for asynchronous users
+
+* bit-rates 50, 75, 110, 150, 200, 300, 600, 1200, 2400, 3600, 4800, 7200, 9600, 12000, 14400, 19200, 24000, 28800, 38400
+* async user rate is adapted to nearest sync user rate
+** new RA0 rate-adaptation function
+** all it does is _stop-bit manipulation_, i.e. inserting,removing extraneous stop bits between characters
+* RA1 + RA2 like in synchronous case
+
+image::v110_figure4.png[width=1200,align="center"]
+
+== V.110 RA0 for asynchronous users
+
+image::v110_table8.png[width=1200,align="center"]
+image::v110_table8contd.png[width=1200,align="center"]
+
+
+== V.110 RA2 from 8/16/32k to 64k
+
+* V.110 just points to I.460
+* in the end, RA2 just means
+** use only LSB of each byte for 8k
+** use two LSB of each byte for 16k
+** use four LSB of each byte for 32k
+
+It reminds a bit 16k sub-slots as in GSM Abis.  
+
+However, V.110 doesn't allow multiplexing of multiple 8/16/32k channels in one 64k channel.
+
+== V.110 synchronization entry/exit
+
+image::v110_figure3.png[width=1200,align="center"]
+
+== V.110 misc features
+
+* synchronous rates of 48 + 56 kbps
+** separate rate adaptation / frame format for those
+* In-band parameter exchange
+* network independent clocking
+** in case you have synchronous communications, but running off a different clock than ISDN
+
+
+== V.110 interworking with modems
+
+* what if an ISDN subscriber with a V.110 TA wants to talk to another subscriber with an analog modem, e.g.  V.32?
+** in theory, the ISDN network could provide an IFW (inter-working function)
+** in practice, that didn't really happen, so it was not supproted in real-world networks
+
+== V.110 usage
+
+* major usage in the context of GSM
+** GSM offers CSD (circuit switched data), a V.110 derivative
+** CSD uses modified V.110 frames
+** GSM-specific interworking function between GSM and ISDN converts to plain V.110
+
+
+== HDLC with syncPPP (RFC1618 / RFC1549)
+
+* Flag octet (0x7E)
+* Address octet (0xFF; all-stations addres)
+* Control octet (0x03; UI frame)
+* FCS (CRC16)
+* optional *compression* suppressing Address + Ctrl on transmit
+
+
+== X.75
+
+* HDLC based protocol
+* 0x7E flag octets
+* address octet
+* 8/16/32bit control field
+* variable-length information field
+* 16bit FCS (CRC16)
+* your usual HDLC/LAPD/LAPB/... type commands: I/RR/RNR/REJ/SABM/DISC/FRMR/UA/DM
+
+
+
+== V.120
+
+* TA for providing V-series applications over ISDN
+** same purpose as V.110
+* unlike V.110: Not based on rate adaptation functions and its own framing format, but HDLC/LAPB based
+* supports operation over _unrestricted_ (64kBps) and _restricted_ (56kBps) [and other] channels
+** made it popular in the US, where restricted 56k user channels were common
+* optionally supports multiplexing of multiple streams as _logical links_ into one B-channel
+* optionally supports V.42bis compression
+
+== V.120
+
+* protocol stack
+** Q.922 as data link layer (LAPB framing)
+** Q.931 as L3 (SETUP/CONNECT/RELEASE/RELEASE_COMPLETE) for establishing logical links
+
+image::v120_figure3_frame_formats.png[align="center"]
+
+== V.120 flow control / modes
+
+* protocol sensitive asynchronous mode
+** I-frames/ABM: flow control by data link layer (RNR frames, withholding V(R) updates)
+** unacknowledged: flow control by RR bit in control state informatoin octet
+* protocol sensitive synchronous mode
+** no flow-control possible
+* bit transparent mode
+** over/underruns may happen in case of clock problems
+
+
+== X.75
+
+* predates ISDN: Specified as part of Packets Switched Public Data Networks
+** X.25 is the UNI (user-network interface) of PSPDNs
+** X.75 is the NNI (network-network interface) of PSPDNs
+** so if German Datex-P interconnected with French Transpac or US Telenet, that was supposedly using X.75 in the 1970s
+
+image::x75_ulema_figure1.png[width=1000,align="center"]
+
+* X.75 SLP (single link procedure) was extended in 1988 for use on ISDN B-channels
+* T.90 contains the specific rules how X.75 is used in ISDN
+
+== X.75 Frame Formats
+
+* looks just like LAPB, LAPD, LAPDm, LAPSat, or any of the other many HDLC derivates
+* but: note the absence of UI-frames! No unacknowledged data transfer
+
+image::x75_table1.png[]
+
+== X.75 Commands and Responses
+
+image::x75_table7.png[]
+
+== X.75 Adresses
+
+image::t90_figure2.png[width=800,float="right"]
+
+* X.75 only uses two addresses (it's point-to-point...)
+** Address _A_ (0x03)
+*** commands from callee to caller
+*** responses from caller to callee
+** Address _B_ (0x01)
+*** commands from caller to calee
+*** responses from callee to caller
+
+== H.221
+
+* bit-stream TDMA system; much more like V.110 or E1 multiframe structure than HDLC based bearers
+* not just frames (like V.110), but _multiframes_ (like E1 or GSM)
+** frame: 80 octets
+** multiframe: 16 frames (1280 octets)
+
+
+== H.221 frame structure
+
+image::h221_figure1.png[width=900,float="right"]
+
+* FAS: _Frame Alignment Signal_
+** alignment pattern (0011011) to lock on multiframe structure
+** control (E/C-bits) and alarm information (A-bits)
+* BAS: _Bit-rate allocation signal_
+** codeword  to describe capability/capacity
+* ECS: _Encryption control signal_
+** optional 800 bit/s channel
+
+== H.221 Frame Alignment Signal
+
+image::h221_figure3.png[width=1400,align="center"]
+
+== H.221 Frame Alignment Signal Multiframe
+
+image::h221_figure4a.png[width=1400,align="center"]
+
+* N1-N4, N5: Mulitframe number
+* C: CRC4
+* TEA: Terminal Equipment Alarm
+
+
+== EOF
+
+End of File