Гельгор А.Л. Сотовые сети мобильной связи стандарта UMTS (2011) (1151872), страница 4
Текст из файла (страница 4)
Функция находится и внутри слоя доступа, и вне его. Она предназначена для распределения ресурсов потоковслужебной или пользовательской информации с целью его передачи сзаданным качеством обслуживания. При этом управление ресурсамивнутри слоя доступа должно быть прозрачным для механизмов, находящихся вне слоя доступа и наоборот.Макроразнесение каналов передачи. Функция расположена внеслоя доступа, но может поддерживаться и внутри слоя в зависимостиот выбранной технологии множественного доступа.Шифрование. Поскольку передача пользовательских данныхпроисходит по открытому радиоканалу, существует необходимостьприменения механизмов шифрования для защиты передаваемой информации, так что данная функция является неотъемлемой частьюслоя доступа.
Вне слоя доступа, например, в области базовой сети,проблема информационной безопасности менее остра, однако, какправило, шифрование опционально применяется и там.Аутентификация пользователя. Пользовательские данные, необходимые для проведения процедуры аутентификации, хранятся внеслоя доступа, следовательно, и функция помещена вне слоя доступа.Кодирование данных источника. Источники пользовательскойинформации (речь, изображение, видео) обладают определенной избыточностью, и для эффективного использования ресурсов системыприменяются различные механизмы кодирования (сжатия) данных,позволяющие заметно снизить эту избыточность.
Функция находитсявне слоя доступа.Кодирование информации в радиоканале. При передаче информации по радиоканалу из-за негативного влияния внешних помех возможно искажение информации. Для противодействия этому вводятся22различные механизмы помехоустойчивого кодирования. Функция находится в слое доступа.Тарификация. Функция, не входящая в слой доступа, представляет собой собственно тарификацию, а также генерирование информации о тарификации, т. е. выставление счетов за услуги.1.3.
ПРИНЦИПЫ ОРГАНИЗАЦИИ СЕТЕВЫХ УСЛУГКлючевыми объектами сетевого взаимодействия являются пользователь, провайдер и услуга, взаимоотношения которых поясняютсячерез совокупность связанных друг с другом определений.Пользователь — объект, находящийся в границах системы и использующий набор разрешенных услуг.Провайдер — абстрактное представление совокупности тех элементов системы, которые обеспечивают предоставление услуг пользователю.Услуга — возможность провайдера к совершению некоторыхдействий, обеспечиваемая в определенных границах системы.Из приведенных определений следует, что определение услуги —это полное выражение поведения провайдера с точки зрения пользователя. При этом само определение услуги не описывает внутреннееповедение провайдера, и существует много механизмов, могущихбыть реализованными для ее обеспечения.Услуга определяется как возможность провайдера, поэтому чтобы сделать услугу пригодной для использования, необходимо какимто образом связать пользователя и услугу.
В результате возникает понятие определения услуги, которое содержит поведение пользователяпо отношению к данной услуге. Заметим, что полное поведение пользователя не является целью определения услуги.В основе определения услуги лежит определенная модель услуги.Рассмотрим общую модель сетевой услуги, которая применима ковсем телекоммуникационным режимам (связь без установки соединения, связь с установкой соединения, одноранговая связь, многоранго-23вая связь и т.д.) на всех семи уровнях модели взаимодействия открытых систем (ВОС) [2].Заданное в модели взаимодействие между пользователем и провайдером составляет абстрактный интерфейс границы услуги.
Этотабстрактный интерфейс называется локальным видом (local view), ион определен в терминах примитивов — элементарных составляющих услуги. Состояние локального вида полностью определяетсяпредшествующей последовательностью примитивов, рассматриваемых в пределах границы услуги.Примитив услуги, исходящей от пользователя к провайдеру, определяется:• содержанием информации, заключенной в примитиве;• ограничениями, наложенными на пользователя, для того, чтобысгенерировать примитив;• требованиями к действию, которым должен ответить провайдерв результате получения примитива.Аналогичным образом, примитив услуги, исходящей от провайдеру к пользователю, определяется:• содержанием информации, заключенной в примитиве;• условиями, которым должен удовлетворять провайдер, для того,чтобы сгенерировать примитив;• возможными ожидаемыми результатами провайдера, касающимися реакциями пользователя при получении примитива.Таким образом, модель услуги описывает виртуальное окружение — содержание примитивов и полный набор взаимоотношениймежду пользователем и провайдером.
В некоторых случаях модель(например, если она описывает услугу прикладного уровня) можетбыть явно описана в спецификациях.Как это ни покажется странным, но, несмотря на большое разнообразие возможных сетевых услуг, изначально существуют всего двабазовых типа примитивов:SUBMIT (ЗАПРОС),24генерируемый пользователем с целью обмена информацией с провайдером, иDELIVER (ДОСТАВКА),отсылаемый провайдером к пользователю в процессе обмена информацией.Пользователь, генерирующий примитив ЗАПРОС, а в результатемогущий получить один или более примитивов ДОСТАВКА, называется запросчиком (REQUESTOR). Пользователь, который получаетпримитив ДОСТАВКА, а в результате может сгенерировать один илиболее примитивов ЗАПРОС, называется получателем (ACCEPTOR).При этом один и тот же пользователь может выступать в качестве запросчика для одних взаимодействий и в качестве получателя — длядругих.Примитивы ДОСТАВКА, исходящие из локального вида, обычновзаимосвязаны с примитивами ЗАПРОС, запрашиваемыми пользователями из других локальных видов.
В некоторых специальных случаях (например, инициированных провайдером) примитив ДОСТАВКАможет быть отослан без каких-либо примитивов ЗАПРОС.Имея два базовых типа примитивов, можно конструировать на ихоснове различные подтипы, отражающие взаимосвязь примитивов водном или нескольких локальных видах, а затем — наборы примитивов различных типов (подтипов).
Имена примитивов структурированы следующим образом:<имя примитива>::=<имя услуги>-<имя примитива услуги>.<типпримитива>,где<тип примитива>::=<базовый примитив>или<тип примитива>::=<подтип примитива>.<базовый примитив>.В данной структуре компонент <имя услуги> — слово, идентифицирующую услугу на одном из семи сетевых уровней.25Компонент <имя примитива услуги> представляет собой однослово, состоящее из индикативной формы глагола (т.
е. изъявительного наклонения) и предназначенное для имени примитива услуги, например,CONNECT (СОЕДИНИТЬ).Компонент <базовый примитив> указывает, является ли примитив типа SUBMIT (ЗАПРОС) или DELIVER (ДОСТАВКА).Компонент <подтип примитива> — одно слово, уточняющеетип примитива, например, REQUESTOR (ЗАПРОСЧИК).При желании структура имен может быть упрощена. В частности,используемые последовательно компоненты <подтип примитива> и<базовый примитив> сокращаются до простого имени в следующихочень часто встречающихся случаях:• взамен REQUESTOR.SUBMIT используется REQUEST(ЗАПРОС);• взамен ACCEPTOR.DELIVER используется INDICATION(ИНДИКАЦИЯ);• взамен ACCEPTOR.SUBMIT используется RESPONSE(ОТКЛИК);• взамен REQUESTOR.DELIVER используется CONFIRM(ПОДТВЕРЖДЕНИЕ).Таким образом, несмотря на то, что исходно базовыми считаютсядва примитива SUBMIT и DELIVER, фактически для реализации сетевых услуг используются четыре базовых примитива: REQUEST,RESPONSE, CONFIRM, INDICATION.Для полного описания примитива необходимо задать его имя, атакже список всех его параметров и их значения, где каждый параметр может относиться к услуге, связанной с передачей служебнойинформации или пользовательских данных.Итак, локальный вид, т.
е. совместное поведение пользователя ипровайдера в границах услуги можно описать посредством перечисления примитивов, генерируемых и принимаемых каждой из сторон26взаимодействия. При этом текущее состояние локального вида полностью определяется предшествующей последовательностью примитивов.Определение набора локальных видов, значимых для определения услуги, требует определения набора возможных состояний длякаждого локального вида. Набор состояний для данного локальноговида определен посредством возможных последовательностей примитивов, которые могут появиться в границах услуги для такого локального вида. Возможная последовательность примитивов ограниченамоделью, которая определяет содержание примитивов, а также связями между примитивами для данного локального вида и примитивамидля других значимых локальных видов.На рис. 1.3 показана модель услуги, предназначенной для четырех пользователей, трое из которых участвуют в обмене примитивамис провайдером.
Каждому пользователю виден только соответствующий локальный вид. Заметим, что в реальности провайдер — это физический объект, характеризующийся неидеальностью характеристик,так что существуют времена задержки между отдельными составляющими услуги; возможность потери, ошибки связи или выполнения в неправильном порядке и т. п.Пользователь AЗапросДоставкаЛокальный видПользователь BЗапросПользователь CДоставкаЛокальный видПользователь DЗапросЛокальный видДоставкаЛокальный видПровайдер услугиРис. 1.3. Модель услуги для четырех пользователей27Обратимся теперь к концепции определения самой услуги. Приэтом заметим, что определение услуги содержит одно или более определений локальных видов.
Когда существует только одно определение всех участвующих локальных видов, услуга называется симметричной, и нет необходимости в их дополнительной идентификации. Соответственно, когда услуга асимметрична, требуются уникальные имена для различения локальных видов, имеющих различныеопределения. Обычно стараются выбрать такие мнемонические имена, чтобы они облегчали понимание протекающих в сети процессов,например, CLIENT и SERVER.Далее отметим, что поскольку услуга — это возможность провайдера к совершению действий, она может быть разделена на части,отражающие обязательность исполнения действий:• обязательная часть;• опциональная часть провайдера;• опциональная часть пользователя.Таким образом, опциональная часть пользователя может бытьлибо опциональной частью провайдера, либо обязательной частью,т. е.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
