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 |