Подуровень конвергенции
В задачи подуровня конвергенции входит принятие от пользователя кадров данных размером до 65535 байт (как раз максимальный размер IP-пакета) и обеспечение на приеме контроля за правильностью доставки информации. Под контролем понимается наблюдение за обнаружение сбоев в последовательности принятых блоков и т.д.
Формат протокольного блока подуровня конвергенции представлен на рис.12. В его составе имеется 4-байтный заголовок и 4-байтный концевик. Поле PAD - это неинформационные добавочные биты, доводящие размер поля данных до величины, кратной 4 байтам.
Рис. 12. Формат CPCS-PDU в AAL типа 3/4
Первым полем в заголовке является поле индикатора общей части (CPI). Оно задумано для того, чтобы интерпретировать содержимое последующих полей, однако на сегодня все поля имеют единственный смысл и это поле не несет информации.
Поле Btag - начальная метка работает в паре с полем Etag - конечная метка. Дело в том, что поскольку размер протокольного блока может быть очень длинный, то когда подуровень сборки/разборки нарежет из этого блока много маленьких блоков фиксированной длины, начало и конец исходного блока попадут в разные селлы при передаче. На приеме же необходимо иметь жесткую связку начала и конца протокольного блока. Поэтому метки начала и конца в каждом блоке всегда одинаковые и увеличиваются на единицу после окончания формирования блока. Нумерация меток ведется в диапазоне от 0 до 255.
Поля BAsize и Длина по сути представляют почти одно и то же - размер протокольного блока. Первое задает размер буфера, который нужно зарезервировать на приеме для того, чтобы принять данный блок, а второе определяет длину поля данных протокольного блока. В принципе это не одно и то же, поскольку исходное пользовательское сообщение может состоять из нескольких таких блоков.
Итак, рассмотрим процесс работы подуровня конвергенции в комплексе. Когда соединение установлено, передатчик активизирует счетчик, по данным которого будет устанавливаться начальная и конечная метка первого блока.
Когда этот блок приходит, передатчик создает заголовок протокольного блока, соединяет его блоком абонентских данных, дополняет объем этого абонентского блока до величины, кратной 4 байтам и прибавляет концевик. В результате получился протокольный блок подуровня конвергенции. Все это целиком отправляется на подуровень сборки/разборки, который нарежет его на куски фиксированной длины по 44 байта, присвоит каждому из них порядковый номер, защитит проверочным полиномом и отправит в канал.
На приеме оказывается, что функция сборки всех маленьких блоков по 44 байта каждый в единый блок данных произвольного размера возложена вовсе не на подуровень сборки/разборки, как можно было бы себе представить, а на подуровень конвергенции. При приеме сервисного блока, содержащего начало протокольного блока система выделяет размер памяти, соответствующий указанному значению в поле BAsize, а метка начала запоминается. Ее потом нужно будет сверить со значением конечной метки в последнем сервисном блоке.
Все проверки на правильность сборки протокольного блока выполняются после того, как будет принят последний кусок с конечной меткой. Проверяется, сходится ли она с начальной меткой, совпадают ли значения, указанные в поле указателя длины поля информации c реальной его длиной, и, если все правильно, блок выдается получателю.
В случае, если обнаружены какие-то расхождения, например, начальная метка не совпадает с конечной, то это значит, что произошла фатальная ошибка передачи, и блок должен быть отброшен, но процедуры восстановления нет. Таким образом, система хорошо ориентирована на обнаружение всевозможных сбоев передачи - одиночных ошибок вставок и выпадений кусков информации, слияний нескольких блоков и т.д. Во всех случаях весь протокольный блок на подуровне конвергенции будет отброшен и получатель никаких уведомлений не получает. На его плечи, таким образом, возлагается функция повторных передач потерянной информации.
