retronetcall / B-channel protocols
After Width: | Height: | Size: 64 KiB |
After Width: | Height: | Size: 78 KiB |
After Width: | Height: | Size: 68 KiB |
After Width: | Height: | Size: 50 KiB |
After Width: | Height: | Size: 22 KiB |
After Width: | Height: | Size: 240 KiB |
After Width: | Height: | Size: 28 KiB |
After Width: | Height: | Size: 48 KiB |
After Width: | Height: | Size: 112 KiB |
After Width: | Height: | Size: 38 KiB |
After Width: | Height: | Size: 106 KiB |
|
@ -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
|
After Width: | Height: | Size: 15 KiB |
After Width: | Height: | Size: 63 KiB |
After Width: | Height: | Size: 60 KiB |
After Width: | Height: | Size: 90 KiB |
After Width: | Height: | Size: 40 KiB |