ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ
Настоящее изобретение относится к системной архитектуре в среде с коммутацией пакетов и более конкретно к реализации в такой архитектуре средств для обеспечения информации о "присутствии" пользователя.
УРОВЕНЬ ТЕХНИКИ
В сетях подвижной связи третьего поколения (3П, 3G) услуги предоставляются через сети, использующие межсетевой протокол, или Интернет-протокол (ИП, IP), что приводит к интеграции приложений для передачи речи и данных. Одним из главных кандидатов на появление новых услуг, основанных на IP, является предоставление информации о "присутствии" пользователя. "Присутствие" определяют как подписку в состоянии связей пользователя и уведомление об изменениях в состоянии связей пользователя. Это состояние связей состоит из следующего: средства связи, адреса связи и статуса пользователя.
В сетях третьего поколения управление вызовом и среда создания услуг основаны на Протоколе инициации сеанса (ПИС, SIP), как описано в документе «Проект партнерства систем 3-го поколения, Группа по техническим спецификациям услуг и системных вопросов, Подсистема IP-мультимедиа - стадия 2, 3G TS 23.228 версия 1.7.0, Февраль 2001 г.».
Документ Комитета инженерной поддержки сети Интернет, Интернет-проект, draft-rosenberg-impp-presence-o1.txt, авторов Розенберг и др., опубликованный 2-го марта 2001 г., содержимое которого включено в состав настоящего документа путем ссылки на Приложение А, предлагает расширение к SIP для подписок и уведомлений "присутствия" пользователя. "Присутствие" пользователя определяют как готовность и способность пользователя взаимодействовать с другими пользователями по сети. Исторически "присутствие" было ограничено индикаторами "on-line" ("интерактивно") и "off-line" ("автономно"). Понятие "присутствия" согласно документу авторов Rosenberg и др. является более широким. Подписки и уведомления "присутствия" пользователя поддерживают с помощью определения пакета событий в рамках используемой SIP общей схемы уведомления о событиях. Этот протокол согласован также со схемой общего "присутствия" и обмена немедленными сообщениями (ОПОНС). Однако такое предложение не включает в себя какое-либо рассмотрение сред мультимедиа.
Расширение SIP, определенное в документе Rosenberg и др., основано на концепции агента "присутствия" (АП), который является новым логическим объектом, способным принять подписки (через сообщения SUBSCRIBE (Подписать)), сохранить состояние подписки и генерировать уведомления (через сообщения NOTIFY (Уведомить)) при наличии изменений в "присутствии" пользователя.
Задачей настоящего изобретения является разработка способа для процедур регистрации, подписки и уведомления, осуществляемых по протоколу инициации сеанса, и предназначенного для подсистемы мультимедиа, использующей Интернет-протокол.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Задачу настоящего изобретения решают посредством оснащения архитектуры сервером "присутствия". Предпочтительно сервер "присутствия" представляет собой часть "глобальной сети" или среды приложений и услуг. Посредством оснащения архитектуры сервером "присутствия" абоненты способны принимать информацию о "присутствии" других абонентов.
Настоящее изобретение относится к стандартизации согласно версии 5/6 ПП3П (Проекта партнерства систем 3-го поколения).
В соответствии с настоящим изобретением разработана среда, использующая коммутацию пакетов и включающая функциональные возможности сервера "присутствия" в среду приложений и услуг.
Среда с коммутацией пакетов является предпочтительно средой мультимедиа, использующей Интернет-протокол, и предпочтительно подсистемой сети с передачей данных, полностью основанной на ИП (ОИП, all-IP).
В первом варианте осуществления функция управления состоянием вызова запроса (ФУСВ-З, I-CSCF) обновляет информацию о "присутствии" в сервере "присутствия" посредством разветвления входящего сообщения REGISTER.
Во втором варианте осуществления функция управления состоянием вызова обслуживания (ФУСВ-О, S-CSCF) действует в качестве агента "присутствия" и сервер "присутствия" обеспечивает задачу сохранения информации об абонентах.
В третьем варианте осуществления сервер "присутствия" в подсистеме мультимедиа, использующей Интернет-протокол (Интернет-мультимедиа, ИМ, IM), действует в качестве агента "присутствия" и функция управления состоянием вызова обслуживания (ФУСВ-О) использует отдельную транзакцию REGISTER для обновления информации о "присутствии" в сервере "присутствия".
Таким образом, изобретение решает задачу маршрутизации сообщений REGISTER (Регистрировать), SUBSCRIBE и NOTIFY в использующей Интернет-протокол подсистеме мультимедиа (ИМ).
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Изобретение далее будет описано посредством ссылки на прилагаемые чертежи, на которых:
Фиг.1 - архитектура по версии 5 ПП3П, в которой воплощено настоящее изобретение;
Фиг.2 - последовательность сообщений REGISTER в первом варианте осуществления настоящего изобретения;
Фиг.3 - последовательность сообщений SUBSCRIBE в первом варианте осуществления настоящего изобретения;
Фиг.4 - последовательность сообщений NOTIFY в первом варианте осуществления настоящего изобретения;
Фиг.5 - последовательность сообщений SUBSCRIBE во втором варианте осуществления настоящего изобретения;
Фиг.6 - последовательность сообщений NOTIFY во втором варианте осуществления настоящего изобретения;
Фиг.7 - последовательность сообщений REGISTER в третьем варианте осуществления настоящего изобретения;
Фиг.8 - последовательность сообщений SUBSCRIBE в третьем варианте осуществления настоящего изобретения; и
Фиг.9 - последовательность сообщений NOTIFY в третьем варианте осуществления настоящего изобретения.
ОПИСАНИЕ ПРЕДПОЧТИТЕЛЬНЫХ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ
В настоящем изобретении сервер "присутствия" помещен в подсистему Интернет-мультимедиа архитектуры, предложенной ПП3П и соответствующей 5 версии, как часть "глобальной сети приложений и услуг". Подсистема мультимедиа, использующая Интернет-протокол, обращается ко множеству элементов базовой сети, которые используют услуги, обеспечиваемые доменом с коммутацией пакетов согласно архитектуре ПП3П, соответствующей 5 версии и предназначенной для предоставления мультимедийных услуг. Элементами подсистемы мультимедиа, использующей Интернет-протокол, являются функция управления состоянием вызова (ФУСВ CSCF), функция управления медиа-шлюзом (ФУМШ (MGCF), функция медиа-ресурсов (ФМР, MRF) и некоторые составляющие для адаптации. Представление расширенной архитектуры показано на Фиг.1.
Фиг.1 основана на базовой архитектуре ПП3П в соответствии с архитектурой, определенной в документе «Проект партнерства систем 3-го поколения, Группа по техническим спецификациям услуг и системных вопросов; Архитектура для сети с общим ИП; 3П (3G) TO (TR) 23.922 версия 1.0.0; Октябрь 1999», содержимое которого включено в состав настоящего документа путем ссылки в качестве Приложения В. Однако архитектура, раскрываемая в настоящем документе, изменена, как показано на Фиг.1, с тем, чтобы включить в ее состав сервер "присутствия" в соответствии с настоящим изобретением.
Конкретно настоящее изобретение касается последовательностей сообщений REGISTER, SUBSCRIBE и NOTIFY в сети ПП3П.
Настоящее изобретение далее будет описано с дополнительными подробностями со ссылками на три иллюстративных варианта осуществления последовательностей сообщений REGISTER, SUBSCRIBE и NOTIFY. Следует отметить, что только необходимые фрагменты сети и последовательностей сообщений, требуемые для пояснения принципа действия настоящего изобретения, описаны в последующих примерах.
Одним общим требованием для всех описанных вариантов осуществления является то, что информация в пользовательском профиле должна содержать имя сервера "присутствия", ассоциированного с этим пользователем.
Маршрутизация сообщений REGISTER/SUBSCRIBE/NOTIFY для первого варианта осуществления описана ниже в настоящем документе со ссылками на Фиг.2 - Фиг.4.
В первом варианте осуществления функция управления состоянием вызова запроса (ФУСВ-З) обновляет информацию о "присутствии" в сервере "присутствия" посредством разветвления входящего сообщения REGISTER.
Первая сеть соответствует визитной сети пользовательского агента "присутствия" (ПАП, PUA) и включает в себя пользовательское оборудование (ПО, UE) 200 и функцию (202) управления состоянием вызова посредника (ФУСВ-П). Первая сеть является также сетью агента "присутствия".
Вторая сеть соответствует домашней сети пользовательского агента "присутствия" (ПАП) и включают в себя функцию 204 управления состоянием вызова запроса (ФУСВ-З), домашний сервер 206 абонента (ов), (ДСА, HSS), функцию 208 управления состоянием вызова обслуживания (ФУСВ-О), и сервер 210 "присутствия" (СП).
Третья сеть соответствует домашней сети абонента и включают в себя ПО абонента 212, первую функцию 214 управления состоянием вызова посредника (ФУСВ№1-П), первую функцию 216 управления состоянием вызова обслуживания (ФУСВ№1-О), функцию 218 управления состоянием вызова запроса (ФУСВ-З), ДСА 220, вторую функцию 222 управления состоянием вызова обслуживания (ФУСВ№2-О) и вторую функцию 224 управления состоянием вызова посредника (ФУСВ№2-П).
На фиг.2 представлена расширенная последовательность сообщений регистрации, соответствующая первому варианту осуществления настоящего изобретения.
Как показано, посредством этапа 230 маршрутизация сообщения REGISTER, инициированного пользовательским оборудованием 200, имеет место между ПО 200, ФУСВ-П 202 первой сети и ФУСВ-З 204 второй сети. Имя сервера 210 "присутствия" является частью абонентского профиля и имя сервера извлекают из ДСА 206 посредством ФУСВ-З 204 на этапе 232. На этапе 234 ФУСВ-З 204 выбирает ФУСВ-О для инициации сеанса и такой функцией в приведенном примере является ФУСВ-О 208.
Как представлено сообщениями 236 и 238, ФУСВ-З 204 разветвляет входящее сообщение REGISTER таким образом, что в соответствии с настоящим изобретением его направляют как к ФУСВ-О 208, так и к СП 210. После этого передают сообщения "200 Успешно" обратно к ПО 300 по обратному маршруту.
На фиг.3 представлена маршрутизация последовательности сообщений SUBSCRIBE, соответствующая первому варианту осуществления настоящего изобретения.
Как представлено сообщениями 240, 242 и 244, сообщение SUBSCRIBE маршрутизируют к ФУСВ-З 204 от абонента 212 ПО через ФУСВ№1-П 214 и ФУСВ№1-О 216.
Как представлено сообщением 246, ФУСВ-З 204 маршрутизирует принятое сообщение SUBSCRIBE непосредственно к СП 210. После этого маршрутизируют сообщения "202 Принято" обратно к абоненту ПО по обратному маршруту.
На фиг.4 представлена маршрутизация последовательности сообщений NOTIFY от сервера 210 "присутствия", соответствующая первому варианту осуществления настоящего изобретения.
Как представлено сообщением 248, сервер 210 "присутствия" пересылает сообщение NOTIFY к ФУСВ-З 218. Следуя локальному запросу к ДСА 220 на этапе 249, ФУСВ-З, как это представлено сообщениями 250, 252 и 254, пересылает сообщение NOTIFY к абоненту 226 ПО через ФУСВ№2-О 222 и ФУСВ№2-П 224. Таким образом, СП 210 посылает сообщение NOTIFY непосредственно к ФУСВ-З 218 других сетей. Еще раз сообщения "200 Успешно" маршрутизируют обратно к СП 210 по обратному маршруту.
Таким образом, первый вариант осуществления устанавливает следующие новые требования к элементам сети, размещенным в архитектуре:
1. ФУСВ-З загружает (часть) пользовательского профиля из ДСА для того, чтобы найти абонентский сервер "присутствия".
2. ФУСВ-З разветвляет входящее сообщение REGISTER от ПАП к ФУСВ-О и к серверу "присутствия".
3. ФУСВ-З маршрутизирует входящие запросы REGISTER непосредственно к серверу "присутствия".
4. Сервер "присутствия" посылает исходящие сообщения NOTIFY непосредственно к ФУСВ-З других сетей.
Маршрутизация сообщений SUBSCRIBE/NOTIFY в соответствии со вторым вариантом осуществления настоящего изобретения описана ниже со ссылкой на Фиг.5 и 6.
Поскольку ФУСВ-З сохраняет абонентский профиль и информацию о контактах, поставляемую в сообщении REGISTER, то простым решением является действие ФУСВ-О в качестве агента "присутствия". Одной возможной проблемой при таком решении является то, что ФУСВ-О должна была бы хранить информацию о всех абонентах и генерировать сообщения NOTIFY ко всем из них.
Следовательно, во втором описываемом варианте осуществления задачу сохранения информации о каждом из абонентов обеспечивает вновь введенный сервер "присутствия". Для ФУСВ-О достаточно принимать только первое сообщение SUBSCRIBE для "представительности", поскольку оно будет генерировать сообщение NOTIFY для одной подписки, и это сообщение NOTIFY будет разветвлено к абонентам посредством прокси-сервера, который имеет информацию об абонентах.
Последовательность регистрации при таком решении соответствует нормальной регистрации, как это определено в документе 3G TS 23.228 версии 1.7.0 от Февраля 2001 года, обсуждаемого выше.
Маршрутизация сообщений SUBSCRIBE/NOTIFY, соответствующая второму варианту осуществления настоящего изобретения, описана ниже со ссылкой на Фиг.5 и 6. Элементы первой, второй и третьей сети, соответствующие элементам, показанным на Фиг.2 - Фиг.4, обозначены на Фиг. 5 и 6 с использованием одинаковых ссылочных позиций.
В дополнение к элементам, показанным на фиг.2-фиг.4, третья сеть, соответствующая домашней сети абонента, включает в себя двух абонентов пользовательского оборудования абон№1 302 ПО и абон№2 304 ПО. Более того, вторая сеть, соответствующая домашней сети ПАП, включает в себя вторую функцию ФУСВ№2-О 306 управления состоянием вызова обслуживания.
На фиг.5 представлена маршрутизация последовательности сообщений SUBSCRIBE, соответствующая варианту осуществления настоящего изобретения.
Сообщение SUBSCRIBE от первого абонента 302 пользовательского оборудования пересылают к ФУСВ№1-П 214, как показано сообщением 308а. Такое сообщение пересылают, в свою очередь, к ФУСВ№1-О 216 и ФУСВ-В 204, как показано сообщениями 310а и 312а. Следуя локальному запросу на этапе 313а, сообщение SUBSCRIBE пересылают к СП 210, как представлено сообщением 314а. Следуя за этим, сообщение SUBSCRIBE пересылают от СП 210 к ФУСВ№2-О 306, как представлено сообщением 316.
В ответ на сообщение 316 SUBSCRIBE от сервера 210 "присутствия", соответствующее первому абоненту 302 пользовательского оборудования, относящегося к третьей сети, ФУСВ№2-О возвращает сообщение подтверждения приема посредством сигнала о принятии, как представлено стрелкой 318.
Подобным образом сообщение SUBSCRIBE от второго абонента 304 пользовательского оборудования пересылают к ФУСВ№1-П 214, как проиллюстрировано сообщением 308b. Такое сообщение пересылают, в свою очередь, к ФУСВ№1-О 216 и к ФУСВ-В 204, как проиллюстрировано сообщениями 310b и 312b. Следуя локальному запросу на этапе 313b, сообщение SUBSCRIBE пересылают к СП 210, как представлено сообщением 314b.
Для сервера 210 "присутствия" нет необходимости пересылать какое-либо из последующих сообщений SUBSCRIBE от пользовательского оборудования третьей сети, поскольку ФУСВ№2-О уже поставила подтверждение об успешном приеме.
Сигналы о принятии для каждого из пользовательских абонентов возвращают соответствующим абонентам по обратным маршрутам в ответ на прием сообщения 318 и соответствующего сообщения 314 SUBSCRIBE.
На Фиг.6 представлена маршрутизация последовательности сообщений NOTIFY от сервера 210 "присутствия", соответствующая варианту осуществления настоящего изобретения.
Как представлено сообщением 320, одиночное сообщение NOTIFY пересылают от ФУСВ№1-О к серверу 210 "присутствия".
Как представлено сообщением 322а, сервер "присутствия" затем пересылает первое сообщение NOTIFY к ФУСВ-З 218. Следуя первому локальному запросу 324а, первое сообщение NOTIFY пересылают к первому абоненту 302 пользовательского оборудования, в свою очередь, через ФУСВ№2-О 222 и ФУСВ№2-П 224, как представлено сообщениями 326а, 328а и 330а.
Сервер "присутствия", как представлено сообщением 322b, также пересылает второе сообщение NOTIFY к ФУСВ-О 218. Следуя второму локальному запросу 324b, второе сообщение NOTIFY пересылают к первому абоненту 302 пользовательского оборудования, в свою очередь, через ФУСВ№2-О 222 и ФУСВ№2-П 224, как представлено сообщениями 326b, 328b и 330b.
Сообщения "200 Успешно" возвращают к серверу 210 "присутствия" по обратному маршруту, и одиночное сообщение "Успешно" пересылают к ФУСВ№1-О.
Маршрутизация сообщений REGISTER/SUBSCRIBE/NOTIFY, соответствующая третьему варианту осуществления настоящего изобретения, описана ниже со ссылкой на Фиг.7 - Фиг.9.
Решение, описанное в третьем варианте осуществления, может быть подытожено как следующее: сервер "присутствия" в подсистеме мультимедиа, использующей Интернет-протокол, действует как агент "присутствия", и ФУСВ-О использует отдельную транзакцию REGISTER для обновления информации о "присутствии" в сервере "присутствия".
Маршрутизация методов REGISTER/SUBSCRIBE/NOTIFY описана далее ниже со ссылкой на Фиг.7 - Фиг.9. Элементы первой, второй и третьей сети, соответствующие элементам, показанным на Фиг.2 - Фиг.6, обозначены на Фиг. 5 и 6 с использованием одинаковых ссылочных позиций.
На фиг.7 представлена расширенная последовательность сообщений регистрации, соответствующая третьему варианту осуществления настоящего изобретения.
Как представлено этапом 230, маршрутизация сообщения REGISTER имеет место между ПО 200, ФУСВ-П 202 первой сети и ФУСВ-З 204 второй сети.
После этого на этапе 702 ФУСВ-З 204 выбирает ФУСВ-О 208 для инициации сеанса и такой функцией в приведенном примере является ФУСВ-О 208.
Как представлено сообщением 704, сообщение REGISTER затем пересылают к ФУСВ-О 208.
Имя сервера 210 "присутствия" является частью абонентского профиля и имя сервера извлекают из ДСА 206 посредством ФУСВ-З 204 на этапе 708.
После успешной инициации с помощью ФУСВ-О 208 сообщение "200 Успешно" передают к ПО 200 по обратному маршруту. После этого, как представлено сообщением 710, сообщение REGISTER пересылают к серверу 210 "присутствия". Сообщение 710 образует отдельную транзакцию, с помощью которой ФУСВ-О обновляет в СП информацию о "присутствии".
Если обновление "присутствия" на сервере "присутствия" завершается неуспешно, то ФУСВ-О генерирует уведомление к ПО 200, указывающее событие неуспешного завершения обновления "присутствия". Для такого уведомления может быть использовано сообщение SIP NOTIFY, например, содержащее заголовок события с кодом причины неуспешного завершения для нового "присутствия". Такой пример, помеченный как 711, показан на Фиг.7. Затем NOTIFY подтверждают элементы от ПО 200 до ФУСВ-О 208, используя сообщение "200 Успешно".
На фиг.8 представлена маршрутизация последовательности сообщений SUBSCRIBE, соответствующая третьему варианту осуществления настоящего изобретения.
Сообщение SUBSCRIBE от абонента 212 пользовательского оборудования пересылают к ФУСВ№1-П 214, как проиллюстрировано сообщением 712. Такое сообщение пересылают, в свою очередь, к ФУСВ№1-О 216 и к ФУСВ-З 204, как проиллюстрировано сообщениями 714 и 716. Следуя локальному запросу на этапе 718, сообщение SUBSCRIBE пересылают к ФУСВ№2-О 306, как представлено сообщением 720. Следуя за этим, сообщение SUBSCRIBE пересылают от ФУСВ№2-О к СП 210, как представлено сообщением 720. После этого сообщение "200 Принято" посылают по обратному маршруту.
На фиг.9 представлена маршрутизация последовательности сообщений NOTIFY от сервера 210 "присутствия", соответствующая третьему варианту осуществления настоящего изобретения.
Как представлено сообщением 722, сообщение NOTIFY пересылают от сервера 210 "присутствия" к ФУСВ№1-О 306. Как представлено сообщением 724, затем ФУСВ№1-О 306 пересылает NOTIFY к ФУСВ-З 218. Следуя локальному запросу на этапе 726, сообщение NOTIFY пересылают к абоненту 226 пользовательского оборудования, в свою очередь, через ФУСВ№2-О 222 и ФУСВ№2-П 224, как представлено сообщениями 728, 730 и 732.
После этого сообщение "200 Успешно" посылают по обратному маршруту.
Новые требования к элементам сети, помещенным в архитектуру согласно третьему варианту осуществления настоящего изобретения, могут быть подытожены как нижеследующие:
1. ФУСВ-О обновляет информацию о "присутствии" в СП с помощью отдельной транзакции REGISTER.
2. Если обновление "присутствия" на СП завершается неуспешно, то ФУСВ-О генерирует к ПО сообщение уведомления (например, SIP NOTIFY, использующее заголовок события с кодом причины неуспешного завершения для нового "присутствия"), указывающее событие неуспешного завершения обновления "присутствия".
3. Сообщение SUBSCRIBE, генерируемое абонентом, должно быть маршрутизировано сетью так, как если бы было обычным сообщением INVITE («Пригласить к участию в сеансе»), только ФУСВ-О для ПАП маршрутизирует SUBSCRIBE к СП, ассоциированному с "представительностью".
4. Сообщение NOTIFY, генерируемое СП, должно быть маршрутизировано сетью так, как если бы было обычным сообщением INVITE.
Несмотря на то что настоящее изобретение было описано со ссылкой на три иллюстративных примера вариантов осуществления, настоящее изобретение в более общей форме представляет способы осуществления идеи, представленной в документе авторов Розенберг и др., предлагаемой архитектуры ПП3П.
Расширения SIP для «Присутствия»
СТАТУС ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ (МЕМОРАНДУМА)
Этот документ является Интернет-проектом и находится в полном соответствии со всеми положениями раздела 10 документа RFC2026.
Интернет-проекты являются рабочими документами Комитета инженерной поддержки сети Интернет (КИПСИ, IETF), его сфер и его рабочих групп. Отметим, что другие группы могут также распространять рабочие документы в качестве Интернет-проектов.
Интернет-проекты являются проектными документами, действительными в течение максимально шести месяцев, и могут быть обновлены, заменены или стать устаревшими для других документов в любое время. Неприемлемо использование Интернет-проектов в качестве ссылочного материала или для цитирования, кроме как для работы, находящейся в развитии.
Перечень текущих Интернет-проектов может быть доступен в документе http://www.ietf.org/ietf/lid-abstracts.txt.
Перечень текущих дубликатов каталогов Интернет-проектов может быть доступен в документе http://www.ietf.org/shadow.html.
Реферат
В документе предложено расширение к SIP для абонентов и уведомлений о присутствии пользователя. Присутствие пользователя определено как готовность и возможность пользователя взаимодействовать с другими пользователями по сети. Исторически присутствие было ограничено индикаторами "on-line" ("интерактивно") и "off-line" ("автономно"); понятие присутствия является более широким. Подписки и уведомления для присутствия пользователя поддерживают посредством определения пакета событий в пределах общей схемы уведомления о событиях, используемой SIP. Этот протокол также согласован со схемой (ОПОНС, CPIM) Общего Присутствия и Обмена Немедленными Сообщениями.
1. Введение
Понятие присутствия (косвенно) определено в RFC2778[1] как подписка к изменениям и уведомление об изменениях в состоянии связей пользователя.
Это состояние связей состоит из множества средств связи, адресов связей и статуса пользователя. Протокол присутствия является протоколом для обеспечения подобной услуги через Интернет или любую сеть с межсетевым протоколом, или Интернет-протоколом (ИП, IP).
В настоящем документе предложено расширение к Протоколу инициации сеанса (ПИС, SIP) [2] для понятия присутствия, или «присутствия». Это расширение является конкретной интерпретацией общей схемы уведомления о событиях, определенной для SIP [3], и как таковое, задает использование методов SUBSCRIBE (Подписать) и NOTIFY (Уведомить), определенных в указанном документе. «Присутствие» пользователя особенно хорошо подходит для SIP. Службы регистрации запросов и местоположения уже содержат информацию о присутствии пользователя; ее загружают на эти устройства посредством сообщений REGISTER и используют для маршрутизации вызовов к этим пользователям. Более того, сети SIP уже маршрутизируют сообщения INVITE от любого пользователя в сети к посреднику, или прокси-серверу, который содержит состояние регистрации для пользователя. Поскольку это состояние является «присутствием» пользователя, то такие сети SIP могут также позволять маршрутизировать запросы SUBSCRIBE к одному и тому же прокси-серверу. Это означает, что сети SIP могут быть повторно используемы для установления глобальной связности подписок и уведомлений «присутствия».
Настоящее расширение основано на понятии «агент присутствия», который является новым логическим объектом, способным к принятию подписок, хранению состояния подписки и генерированию уведомлений в том случае, когда происходят изменения в состоянии «присутствия» пользователя. Объект определен как логический, поскольку обычно он совместно размещен с другим объектом, и даже может быть перемещен в течение времени жизни подписки.
Настоящее расширение согласовано также со схемой Общего Присутствия и Обмена Немедленными Сообщениями (ОПОНС, CPIM), которая была определена в [4]. Это позволяет протоколу SIP для «присутствия» легко взаимодействовать с другими системами «присутствия», согласованными со ОПОНС.
2. Определения
Настоящий документ использует термины так, как это определено в [1]. Дополнительно следующие термины определены и/или дополнительно пояснены:
«Пользовательский агент присутствия» (ПАП, PUA): Пользовательский агент присутствия управляет информацией о «присутствии» для «представительности». В терминах SIP это означает, что ПАП генерирует запросы REGISTER, передавая некоторый вид информации о «представительности». В явной форме допускают множество ПАП для «представительности». Это означает, что пользователь может иметь много устройств, таких как сотовый телефон или персональный цифровой ассистент (PDA), каждый из которых независимо генерирует компонент общей информации о «присутствии», предназначенной для «представительности». ПАП помещают данные в систему присутствия, но находятся вне системы, так что они не принимают сообщений SUBSCRIBE и не посылают сообщений NOTIFY.
«Агент присутствия» (АП, РА): Агент присутствия является пользовательским агентом SIP, который способен к приему запросов SUBSCRIBE, к ответу на них и к генерированию уведомлений об изменениях в состоянии «присутствия». Агент присутствия должен иметь полное знание о состоянии «присутствия» (для) «представительности». Обычно это достигают посредством совместного размещения АП с прокси-сервером/ сервером-регистратором запросов или с «пользовательским агентом присутствия» (для) «представительности». АП всегда адресуем с помощью URL (Унифицированный адрес ресурса, УАР, URL) SIP.
«Сервер присутствия»: Сервер присутствия является логическим объектом, который для запросов SUBSCRIBE может действовать и как агент присутствия, и как прокси-сервер. При действии в качестве АП сервер присутствия посредством некоторых средств протокола осведомлен об информации «присутствия» для «представительности». Эти средства протокола могут быть запросами SIP REGISTER, но позволены и другие средства реализации. При действии в качестве прокси-сервера запросы SUBSCRIBE передают к другому объекту, который может действовать как АП.
«Клиент присутствия»: клиент присутствия является агентом присутствия, который размещен совместно вместе с ПАП. Он осведомлен об информации «присутствия» «представительности», поскольку он размещен совместно с объектом, который управляет этой информацией о «присутствии».
3. Обзор принципа действия
В данном разделе представлен обзор принципа действия настоящего расширения.
Когда объект, абонент, желает узнать об информации «присутствия» от некоторого пользователя, он создает запрос SUBSCRIBE. Этот запрос идентифицирует требуемую «представительность» в URI (Унифицированный идентификатор ресурса, УИР, URI) запроса, используя или URL «присутствия», или URL SIP. Подписку переносима по прокси-серверам SIP, как любой другой INVITE. Она, возможно, прибывает на сервер присутствия, который может либо завершить подписку (в таком случае он действует как агент присутствия для «представительности»), либо передать ее к клиенту присутствия. Если клиент присутствия обрабатывает подписку, то он фактически действует как агент присутствия для «представительности». Решение о том, передать или завершить SUBSCRIBE, является предметом локального рассмотрения; однако будет описан один способ осуществления такой схемы с использованием REGISTER.
Агент присутствия (либо в сервере присутствия, либо в клиенте присутствия) сначала аутентифицирует подписку, затем авторизует ее. Средства для авторизации находятся вне рамок области действия настоящего протокола, и ожидают, что будут использованы многие средства и способы. Авторизовав подписку, агент присутствия посылает ответ «202 Принято» (Accepted). Он также посылает немедленное сообщение NOTIFY, содержащее состояние «представительности». Поскольку состояние «представительности» изменено, то АП генерирует сообщения NOTIFY для всех абонентов.
Сообщение SUBSCRIBE фактически образует сеанс вместе с агентом присутствия. В качестве результата, SUBSCRIBE может быть маршрутизирован по записям и правила для обработки меток полей и информации об «Адресах переназначения» (Contact) отображают подобные правила для INVITE. Подобным образом, сообщение NOTIFY обрабатывают во многом сходным образом с тем, как обрабатывают повторный INVITE внутри этапа вызова.
4. Наименование
«Представительность» идентифицируют наиболее общим образом через URI [4], который представлен в форме pres:@domain. Такие URI не зависят от протокола. Посредством разнообразных средств такие URI могут быть разрешены для определения конкретного протокола, который может быть использован для доступа к представительности. Если один раз такое разрешение имело место, то «представительность» может быть адресована с помощью URL протокола SIP в почти идентичной форме: SIP:user@domain. Протокольно независимую форму (представительность: URL) можно считать абстрактным именем, такого вида как URN, которое используют для идентификации элементов в системе «присутствия». Их разрешают к конкретным URL, которые могут быть использованы для непосредственного, или прямого, определения местоположения этих элементов в сети.
При подписке к «представительности» подписка может быть адресована с использованием протокольно независимой формы или формы URL SIP. В контексте SIP "адресована" означает URI запроса. Рекомендуют, что если объект, посылающий SUBSCRIBE, способен разрешить протокольно независимую форму к форме SIP, то такое разрешение делают перед посылкой запроса. Однако если объект не способен сделать такое преобразование, то протокольно независимую форму используют в URI запроса. Выполнение такого преобразования как можно ранее означает, что такие запросы могут быть маршрутизированы прокси-серверами SIP, которые не осведомлены о пространстве имен присутствия.
Результатом такой схемы именования является то, что запрос SUBSCRIBE адресуют к пользователю точно таким же образом, как был бы адресован INVITE. Это означает, что сеть SIP будет маршрутизировать эти сообщения по тому же маршруту, по которому будет путешествовать INVITE. Один из этих объектов по маршруту может действовать в качестве АП для подписки. Обычно это будет или сервер присутствия (который является прокси-сервером/сервером-регистратором запросов там, где регистрирован пользователь), или клиент присутствия (который является одним из пользовательских агентов, ассоциированных с данной «представительностью»).
Сообщения SUBSCRIBE также содержат логические идентификаторы, которые определяют отправителя и получателя подписки (поля заголовка То (Конечный получатель) и From (Отправитель)). Поскольку эти идентификаторы являются логическими, то рекомендуют, чтобы для них по возможности использовали протокольно независимую форму. Это также упрощает межсетевое взаимодействие с другими системами, которые распознают эти формы.
Поля Contact («Адреса переназначения»), Record-Route («URI запроса»), Route («Маршрут запроса») не являются логическими объектами, а скорее конкретизируют те, которые используют для передачи сообщений SIP. Являясь такими, они должны использовать формы URL SIP в сообщениях SUBSCRIBE и NOTIFY.
5. Пакет событий для присутствия
Используемая SIP схема [3] событий определяет абстрактное расширение SIP для подписки к событиям и приема уведомлений от событий. Схема оставляет определение многих дополнительных аспектов для событий, чтобы конкретизировать расширения, известные также как пакеты событий. Это расширение квалифицировано как пакет событий. Настоящий раздел пополняет информацию, требуемую для [3].
5.1. Имя пакета
Именем этого пакета является "presence" ("присутствие"). Это имя должно появиться внутри заголовка события в запросе SUBSCRIBE и в запросе NOTIFY. Настоящий раздел служит также в качестве регистрации НИНА (IANA, Назначаемые Интернет номера авторизации, НИНА) для пакета событий "presence".
Сделать: определить шаблон НИНА в подуведомлении и заполнить его.
Пример:
Event: presence
5.2. Тела SUBSCRIBE (подписок)
Тело запроса SUBSCRIBE может содержать тело (подписки). Назначение тела зависит от его типа. В общем случае, подписки обычно не будут содержать тел. URI запроса, который идентифицирует «представительность», объединенный с именем пакета событий, достаточен для пользовательского «присутствия».
Следует предупредить, что форматы документа могут быть определены как фильтры для подписок. Такие фильтры будут указывать некоторые события пользовательского «присутствия», которые будут генерировать уведомления, или сокращать совокупность данных, возвращаемых в запросах NOTIFY. Например, фильтр «присутствия» может указать, что уведомления следует генерировать, когда изменяется статус входного (почтового) ящика немедленных сообщений пользователей. Можно также сказать, что в состав содержимого этих уведомлений следует включать только относящуюся к НС информацию. (IM: «немедленное сообщение» - ближе по тексту, «интерактивный режим» - по стандартным сокращениям, Интернет-мультимедиа - по документу.)
5.3. Время завершения
Присутствие пользователя может быть изменено в результате событий, которые включают в себя:
включение и выключение сотового телефонного аппарата;
модификация регистрации с программофона;
изменение статуса инструментальных средств немедленных сообщений.
Эти события обычно срабатывают под воздействием пользователя и происходят с частотой, значение которой порядка минут или часов. Если так, то подпискам следует иметь время завершения, равное среднему для этого диапазона и которое приблизительно соответствует одному часу. Следовательно, время завершения по умолчанию для подписок является 3600 секунд. Согласно [3] абонент может указать другое время завершения. Что бы не было указано во времени завершения, сервер может уменьшить его, но не должен увеличить его.
5.4. Тела NOTIFY
Тело уведомления содержит документ «присутствия». Этот документ описывает «присутствие» пользователя для «представительности», к которой была осуществлена подписка. Все подписки должны поддерживать формат данных «присутствия», который описан в [заполнить с IMPP документом TBD], и должны перечислять свой тип МРПСИ (Многоцелевые расширения почтовой службы Интернет, стандарт MIME, МРПСИ), [заполнить с типом МРПСИ] в заголовке Accept, содержащемся в запросе SUBSCRIBE.
Другие форматы данных присутствия могут быть определены в будущем. В таком случае подписки могут указать поддержку для других форматов «присутствия». Однако они должны всегда поддерживать любой перечень МРПСИ [заполнить с типом МРПСИ документа «присутствия» IMPP] как допустимый формат.
Конечно, уведомления, генерируемые агентом присутствия, должны быть в одном из форматов, указанном а заголовке Accept в запросе SUBSCRIBE.
5.5. Обработка требований на АП
«Присутствие» пользователя является высокочувствительной информацией. Поскольку последствия разглашения информации о «присутствии» могут быть суровыми, то на АП накладывают строгие требования, касающиеся обработки подписки, особенно относящиеся к аутентификации и авторизации.
Агент "присутствия" должен аутентифицировать все запросы подписки. Такая аутентификация может быть сделана с использованием любых средств и способов, определенных для SIP. Для аутентификации не считается достаточным быть транзитивной; то есть для аутентификации следует использовать средства сквозного контроля. Не должны быть использованы базовые средства аутентификации, определенные протоколом SIP.
Рекомендуют, чтобы любые подписки, которые не аутентифицированы, не вызывали состояния быть созданными в АП. Это может быть выполнено посредством генерирования кода 402 в ответе на сообщение SUBSCRIBE и затем отбрасыванием полного состояния для этой транзакции. Повторные передачи SUBSCRIBE генерируют тот же ответ, гарантируя надежность даже над UDP (ПДП, UDP).
Более того, АП не должен принимать подписку, если только авторизация не была обеспечена «представительностью». Средства, которые обеспечивают авторизацию, лежат вне объема рассмотрения настоящего документа. Авторизация может быть обеспечена, предваряя время, посредством перечней доступа, возможно, указанных на Web-странице. Авторизация может быть обеспечена средствами подкачки документа с перечнем стандартизованного управления доступом. Серверы оконечной, или серверной части, авторизации такие, как DIAMETER[5], RADIUS[6], COPS[7], также могут быть использованы. Полезно также иметь возможность запросить пользователя для авторизации, следуя за приемом запроса на подписку, для которой не представлено никакой информации по авторизации. Приложение А представляет возможное решение для такого сценария.
Результатами принятия решения сервером об авторизации будут отвергнуть, принять или ожидание. Ожидание происходит тогда, когда не может получить авторизацию в данное время, и может быть способен сделать это в более позднее время, когда «представительность» становится доступной.
К сожалению, если сервер информирует абонента, что подписка находится в ожидании, это будет разглашением информации о «представительности», а именно что не гарантируется авторизация и что нет возможности получить ее в данное время. Поэтому АП следует генерировать одинаковый ответ для обеих подписок: ожидающей и принятой. Такому ответу следует быть ответом «202 Принято».
Если сервер информирует абонента, что подписка отвергнута, то это также разглашает информацию о «представительности», а именно в том, что они (сервер) явным образом предварительно заблокировали подписку, или они доступны в данное время и сделали выбор отклонить подписку. Если политикой сервера является не разглашать информацию, то АП может ответить посредством ответа «202 Принято» даже несмотря на то, что подписка отвергнута. В качестве альтернативы, если политикой «представительности» или АП является то, что допустимо информировать абонента об отказе, то следует использовать «603 Decline» (Отклонить).
Отметим, что поскольку ответ на подписку не содержит какой-либо полезной информации о «представительности», то секретность и целостность ответов SUBSCRIBE не считают важной.
5.6. Генерирование уведомлений
После приема подписки АП следует генерировать немедленный NOTIFY с текущим состоянием «присутствия» для «представительности».
Если подписка принята и отмечена как ожидающая или была отвергнута, то АП следует генерировать немедленный NOTIFY. Этому NOTIFY следует содержать действительное состояние для "представительности", однако будучи тем, что не обеспечивает полезной информации о "представительности". Примером этому является обеспечение адреса URL IM, который является такой же формой, как и URL "присутствия", и отметить такой адрес IM как "недоступен". Причиной для такого процесса "лжи" является то, что без него абонент сможет понять различие между ожидающей подпиской и принятой подпиской на основании существования и содержимого немедленного NOTIFY. Подход, определенный в настоящем документе, гарантирует, что "присутствие", доставленное в NOTIFY, сгенерированном по ожидающей или отвергнутой подписке, является также действительным, которое могло быть доставлено в NOTIFY, сгенерированном по принятой подписке.
Если политика сервера "присутствия" или "представительности" является такой, что приемлемо разглашение информации о том, была ли подписка успешной или нет, то нет необходимости в посылке немедленного NOTIFY для ожидающей или отвергнутой подписки.
Конечно, поскольку подписка принята, то АП следует генерировать NOTIFY для подписки, когда АП определяет, что состояние "присутствия" для "представительности" было изменено. Раздел 6 описывает, как АП осуществляет это определение.
По причинам секретности часто будет необходимо шифровать содержимое уведомлений. Это можно выполнить с использованием стандартных средств и способов SIP. Шифрование следует выполнять с использованием ключа абонента, идентифицированного в поле From в SUBSCRIBE. Подобным образом, абонентам важна целостность уведомлений. Раз так, то содержимое уведомлений следует аутентифицировать с использованием одного из стандартизованных средств SIP. Поскольку NOTIFY генерированы сервером присутствия, который может не иметь доступа к ключу пользователя, представленного "представительностью", это часто бывает тем случаем, когда NOTIFY подписан третьим лицом. Рекомендуют, чтобы подпись была авторизацией над доменом "представительности". Другими словами, для пользователя, соответствующего pres:user@example.com, лицо, подписывающее NOTIFY, должно иметь полномочия для example.com.
5.7. Ограничения на частоту NOTIFY
По причинам управления перегруженности важно, чтобы частота уведомлений не становилась чрезмерной. Как результат, рекомендуют, чтобы АП не генерировал уведомления для одиночной "представительности" с частотой более высокой, чем один раз в 5 секунд.
5.8. Поведение для обновления
Поскольку SUBSCRIBE маршрутизируют посредством прокси-серверов, как и любым другим способом, то вероятно, что подписка может быть разветвлена. Как результат она может прибыть на множественные устройства, которые настроены для действий в качестве АП для той же самой "представительности". Каждый из них будет отвечать на SUBSCRIBE (с) ответом 202. На основании правил разветвления, используемых в SIP, только один из этих ответов передают абоненту. Однако абонент будет принимать уведомления от каждого из этих АП, которые приняли подписки. Используемая SIP схема событий дает возможность каждому пакету определить обработку для такого случая.
Обработка в этом случае идентична способу, которым обрабатывался бы INVITE. Ответ «202 Принято» на SUBSCRIBE приведет к установке состояния подписки в абоненте. Подписка ассоциирована с From и То (оба из них с метками) и с Call-ID («Идентификатор клиента») из 202. Когда уведомления прибывают, то те от АП, ответы с кодом 202 которых были отвернуты в разветвляющем прокси-сервере, не найдут совпадения с ИД подписки, хранимым у абонента (метки для From будут различными). На это следует отвечать (с) кодом 481. Это запретит подписки от таких АП. Более того, при регенерации, или обновлении, подписки регенерации следует использовать метки из 202 и использовать любые из заголовков Contact или Record-Route для того, чтобы доставить SUBSCRIBE обратно к тому же АП, который послал 202.
Результат этого заключается в том, что "представительность" может иметь множество активных АП, но они должны быть однородными, так что каждый может генерировать одинаковое множество уведомлений для "представительности". Поддержка однородных АП, каждый из которых генерировал бы уведомления для подмножества данных "присутствия", является сложной и трудной для управления задачей. Если такое свойство необходимо, то скорее оно может быть выполнено посредством B2BUA, чем через разветвляющий прокси-сервер.
6. Публикация
«Присутствие» пользователя для "представительности" может быть получено любым количеством различных способов. Основа SIP определяет метод, который используют все клиенты SIP - метод REGISTER. Этот метод позволяет ПА (UA, «Пользовательский агент») информировать сеть SIP об адресах текущих связей (например, адресы Contact). Более того, множество ПА могут независимо регистрировать адресы Contact для одного и того же URL SIP. Эти адресы Contact могут быть адресами URL SIP, или они могут быть любым другим действительным URL.
Использование информации регистрации для "присутствия" является прямой (открытой). Адрес записи в REGISTER (поле То) идентифицирует "представительность". Заголовки Contact определяют адреса связей, которые описывают состояние "представительности". Рекомендуют применение расширения [8] SIP для предпочтительных, или глобальных, установок для вызывающего абонента, для использования с теми ПА, которые заинтересованы в "присутствии". Это обеспечивает дополнительную информацию об адресах Contact, которые могут быть использованы для создания более насыщенного (богатого) документа «присутствия». Атрибут "описание" заголовка Contact определен в нем явным образом, чтобы быть использованным как поле свободной формы, что дает возможность пользователю определить статус "представительности" в адресах связей.
Допускают также, чтобы запросы REGISTER содержали документы присутствия, так что ПАП могут публиковать более сложную информацию.
Отметим, что не предусмотрены средства и способы блокировки, которые разрешили бы клиенту блокировать состояние "присутствия", извлекать его и обновлять его автоматически. Авторы полагают, что это не потребуется для большинства вариантов использования и вводит основательную сложность. Большинство операций "присутствия" не требуют выполнения по схеме "сначала получи - потом установи", поскольку средства SIP для регистрации работают таким образом, что данные могут быть обновлены без "получи".
Применение регистрированных контактов к "присутствию" повышает требования к аутентичности, или подлинности. Поэтому запросы REGISTER, используемые пользовательскими агентами "присутствия", должны быть аутентифицированы с применением либо средств и способов аутентификации SIP, либо средств и способов последовательного подтверждения.
Для указания "присутствия" для обмена немедленными сообщениями ПА может либо регистрировать адресы контактов, которые являются URL SIP со множеством параметров "методов", которые установлены для указания метода MESSAGE (Сообщение), или он может регистрировать URL НС.
Необходимо сделать: данный раздел требует работы. Необходимо определить конкретный пример отображения регистрации на документ присутствия, поскольку IMPP генерирует формат документа.
6.1. Миграция функции АП
Важно представлять, что функция АП может быть совместно размещена с несколькими элементами:
Она может быть совместно размещена с прокси-сервером, обрабатывающим регистрации для "представительности". Таким способом, АП знает о "присутствии" пользователя через регистрацию.
Она может быть совместно размещена с ПАП для этой "представительности". В случае единственного ПАП для "представительности" ПАП знает состояние "представительности" по явной сути совместного размещения.
Она может быть совместно размещена в любом прокси-сервере на пути установки вызова. Такой прокси-сервер может узнать состояние "присутствия" для "представительности" посредством генерирования своего собственного SUBSCRIBE для того, чтобы это определить. В этом случае АП в действительности является B2BUA.
Поскольку состояния подписок программируемы по сути, то для функций АП становится возможной миграция в течение времени жизни подписки. Наиболее работоспособным сценарием для функций АП является миграция от сервера "присутствия" к ПАП и обратно.
Рассмотрим подписку, которая установлена на сервере "присутствия". Предположим, что сервер "присутствия" может определить, что вызываемый ПА способен действовать в качестве АП для "представительности". Когда прибывает регенерация подписки, АП уничтожает свою подписку и затем действует в качестве прокси-сервера для подписки. Затем подписку маршрутизируют к ПА, на котором она может быть принята. Результатом является то, что подписка становится установленной на ПАП.
Чтобы такая миграция работала, ПАП должен быть подготовлен к принятию запросов SUBSCRIBE, которые уже содержат метки в поле То («конечный получатель»). Более того, ПАП должен вставить заголовок Contact в 202, и этот заголовок должен быть использован абонентом для обновления адреса контактов для подписки.
Необходимо сделать: Это работает? Как насчет получения Record-Route вместо ПАП. Это может быть возможно только для обновлений, которые не используют Route или метки.
Сервер "присутствия" определяет, что ПАП способен к поддержке функций АП через сообщения REGISTER. Конкретно, если ПАП хочет указать поддержку для функции АП, ему следует включить в состав своей регистрации адрес контакта вместе с параметром "методов", который используют для предпочтительных установок для вызывающего абонента, включающих в состав SUBSCRIBE.
7. Отображение на ОПОНС
В настоящем разделе определено, как сообщения SIP для "присутствия" преобразуют в ОПОНС и как сообщения ОПОНС преобразуют в SIP для "присутствия". Преобразование SIP к ОПОНС происходит, когда система SIP посылает запрос SUBSCRIBE, который содержит URL «pres» или URL SIP, соответствующий пользователю в домене, реализующем другой протокол "присутствия". Отображение ОПОНС на SIP вовлекает в себя случай, при котором пользователь в домене с отличающимся протоколом генерирует подписку, которая предназначена для пользователя в домене SIP.
Отметим, что процесс, определенный ниже, требует, чтобы шлюз хранил состояние подписки. Этот неудачный результат обязан необходимости запоминать заголовки Call-ID, CSeq («Номер последовательности команд») и Route для подписок со стороны SIP, так что они могут быть вставлены в SIP NOTIFY, генерируемые при прибытии уведомлений ОПОНС.
7.1. Отображение SIP в ОПОНС
SIP для "присутствия" конвертируют к ОПОНС через услугу абстрактного шлюза «SIP к ОПОНС», изображенного на Фиг.1.
Фиг.1. Преобразование SIP к CPIM
Первым этапом является то, что запрос SUBSCRIBE принимают на шлюзе. Шлюз генерирует запрос ОПОНС на подписку, у которого параметры заполнены так, как следует ниже:
Идентификатор имени «наблюдателя», или «контролера», копируют из поля From запроса SUBSCRIBE. Если поле From содержит URL SIP, то его преобразуют к эквивалентному URL pres посредством удаления всех параметров URL SIP и изменением схемы к pres.
Это преобразование может не работать - что если URL SIP не имеет имени. Кроме того, преобразование от URL обратно к URN может не сделать это корректно.
Идентификацию цели в сообщении ОПОНС копируют из поля Request-URI (Адрес текущего получателя) из SUBSCRIBE. Это также может потребовать преобразования к URL pres.
Параметр продолжительности в сообщении ОПОНС копируют из заголовка Expires («Продолжительность действительности значения URI») из SUBSCRIBE. Если заголовок Expires указывает абсолютное время, то его преобразуют посредством шлюза к дельта-времени, или ко времени, выраженном в приращениях. Если заголовок Expires отсутствует, то продолжительность полагают равной одному часу.
Параметр transID («Идентификатор транзакции») в сообщении ОПОНС составляют посредством присоединения Call-ID, URI из поля То, URI из поля From, CSeq и метки из поля From, и Request-URI, и вычислением хэш-значения для результирующей строки. Это хэш-значение используют в качестве transID. Отметим, что Request-URI включен в состав хэш-значения. Это делают для различения таких разветвленных запросов внутри сети SIP, которые могут прибыть на тот же шлюз.
Служба ОПОНС затем отвечает либо об успешном, либо о неуспешном выполнении. В случае успешного выполнения служба шлюза «SIP к ОПОНС» генерирует для SUBSCRIBE ответ 202. Она добавляет метку к полю То в ответе, которое является тем же, что и поле transID в ответе об успешном выполнении. Ответ 202 содержит также заголовок Contact, который является значением цели из запроса SUBSCRIBE. Важно, чтобы заголовок Contact был установлен на цель, поскольку это создает уверенность, что регенерации подписок имеют то же значение Request-URI, что и в исходной подписке. Значение продолжительности из ответа об успешном выполнении помещают в заголовок Expires ответа 202. Шлюз хранит Call-ID и Route заголовка, установленные для этой подписки.
Если служба ОПОНС отвечает о неуспешном выполнении, то шлюз «SIP к ОПОНС» генерирует ответ 603. Он добавляет метку к полю То в ответе, которая является такой же, как и поле transID для ответа о неуспешном выполнении.
Когда система ОПОНС генерирует запрос на уведомление, то шлюз «SIP к ОПОНС» создает запрос SIP NOTIFY. Запрос составляют с использованием процедур стандарта RFC2543 [2], предназначенных для создания запроса в пределах разветвленного вызова (т.е. вызова со множественными ответами на разветвленный запрос). Это приведет к тому, что поле То содержит поле «контролера» из ОПОНС, и поле From содержит поле цели из уведомления ОПОНС. Метка в поле From будет содержать transID. Информацию о "присутствии" копируют в тело уведомления. Заголовки Call-ID и Route составляют из состояния подписки, хранимого на шлюзе. Если еще не было генерировано уведомление для данной подписки, то выбирают и сохраняют начальное значение CSeq.
Регенерации SUBSCRIBE обрабатывают аналогично обработке начальных подписок, как описано выше.
Если подписка принята с нулевым значением Expires, то шлюз «SIP к ОПОНС» генерирует в систему ОПОНС сообщение «не подписать». Параметр «контролера» копируют из поля From из SUBSCRIBE. Параметр цели копируют из поля Request-URI из SUBSCRIBE. TransID копируют из метки в поле То запроса SUBSCRIBE.
Ответом на «не подписать» является либо успешное, либо неуспешное выполнение. В случае успешного выполнения ответ 202 составляют по тому же образу, как и выше для ответа абоненту ОПОНС об успешном выполнении. Полное состояние подписки удаляют. В случае неуспешного выполнения ответ 603 составляют по тому же образу, как и выше, и затем состояние подписки удаляют, если оно существовало.
7.2. Отображение ОПОНС в SIP
Преобразование от ОПОНС в SIP происходит, когда запрос на подписку ОПОНС прибывает на сторону шлюза, соответствующую ОПОНС. Этот сценарий показан на Фиг.2.
Запрос на подписку преобразуют в запрос SIP SUBSCRIBE. Чтобы сделать это, на первом этапе определяют, относится ли данная подписка к существующей подписке. Это осуществляют выборкой цели из запроса на подписку и сравнением ее на соответствие с целями для существующих подписок. Если таковых нет, то это - новая подписка, иначе это - регенерация.
Если это новая подписка, то шлюз генерирует запрос SIP SUBSCRIBE следующим образом:
Поле From в запросе устанавливают по полю «контролер» (из) запроса ОПОНС на подписку.
Поле То в запросе устанавливают по полю «цель» (из) запроса ОПОНС на подписку.
Заголовок Expires в запросе SUBSCRIBE устанавливают по полю «продолжительность» (из) запроса ОПОНС на подписку.
Цель в поле From устанавливают по transID (из) запроса ОПОНС на подписку.
Фиг.2. Преобразование CPIM к SIP
Затем посылают сообщение SUBSCRIBE.
Если подписка является регенерацией, то запрос SUBSCRIBE генерируют таким же образом. Однако будут также метка в поле То, которую копируют из состояния подписки на шлюзе, и заголовок Route, полученный из состояния подписки на шлюзе.
Когда принят ответ на SUBSCRIBE, то ответ посылают к системе ОПОНС. Параметр «продолжительность» в этом ответе копируют из заголовка Expires ответа SUBSCRIBE (может быть необходимым преобразование от абсолютного времени ко времени, выраженном в приращениях). TransID в ответе копируют из метки поля From ответа. Если ответом был 202, то статус устанавливают как «неопределенный». Если ответом был любой другой ответ класса 200, то статус устанавливают как «успешный». Для любого другого конечного ответа статус устанавливают как «неуспешный».
Если ответом был ответ класса 200, то состоянием подписки является «создана». Это состояние содержит метку из поля То ответа SUBSCRIBE, и заголовок Route устанавливают вычисленным по заголовкам Record-Routes и Contact ответа класса 200. Подписку индексируют по идентификации «представительности» (поле То из сгенерированного запроса SUBSCRIBE).
Если со стороны ОПОНС принят запрос «не подписать», то шлюз проверяет, существует ли подписка. Если это так, то SUBSCRIBE генерируют, как описано выше. Однако заголовок Expires устанавливают в нуль. Если подписка не существует, то шлюз генерирует ответ о неуспешном выполнении и посылает его к системе ОПОНС. Когда прибывает ответ на SUBSCRIBE, его преобразуют к ответу ОПОНС, как описано выше для ответа на начальный SUBSCRIBE. В всех случаях уничтожают любое состояние подписки на шлюзе.
Когда NOTIFY принят со стороны системы SIP, то посылают запрос ОПОНС об уведомлении. Это уведомление создают как нижеследующее:
Поле «контролер» ОПОНС устанавливают по значению URI поля То из NOTIFY.
Цель ОПОНС устанавливают по значению URI поля From из NOTIFY.
TransID вычисляют, используя такие же средства, как и для SUBSCRIBE согласно разделу 7.1.
Компонент «присутствия» в уведомлении выделяют из тела запроса SIP NOTIFY.
Шлюз генерирует ответ 200 на SIP NOTIFY и также посылает его.
Необходимо сделать: некоторые схемы последовательностей вызовов с параметрами.
8. Брандмауэр и прохождение ПСА (NAT - Преобразование сетевых адресов, ПСА)
Предвидят, что услуги «присутствия» будут использованы клиентами и «представительностями», которые соединены с прокси-серверами по другую сторону брандмауэров, или системы защиты доступа, и ПСА. Удачно, что поскольку сообщения SIP «присутствия» не образуют независимых потоков данных, как это делает INVITE, то прохождение брандмауэра и ПСА являются намного более простыми, чем описано в [9] и [10].
Обычно данные проходят ПСА и брандмауэры, когда их посылают по соединениям TCP или TLS (протокол Безопасности на транспортном уровне), созданным устройствами внутри брандмауэра/ПСА, к устройствам вне них. В качестве результата рекомендовано, чтобы SIP для объектов «присутствия» поддерживал постоянные соединения ТСР или TLS с их следующими узлами пересылки. Это включает в себя соединения, открытые для посылки SUBSCRIBE, NOTIFY, и что более важно, REGISTER. При поддержке последнего из указанных соединений открытым, оно может быть использовано прокси-сервером SIP для посылки сообщений извне брандмауэра/ПСА обратно к клиенту. Рекомендуют также, чтобы клиент при регистрации включал в состав регистрационных файлов на клиентской стороне, или cookie-файлов, строку данных для Contact, как описано в [10], чтобы прокси-сервер мог отобразить URI «представительности» для этого соединения.
Более того, объекты либо на стороне брандмауэра, либо ПСА должны иметь запись маршрута, чтобы гарантировать, что начальное соединение, созданное для подписки, используют также и для уведомлений.
9. Рассмотрения безопасности
Для «присутствия» существуют многочисленные рассмотрения безопасности. Многие из них были охарактеризованы выше; данный раздел рассматривает их вопрос за вопросом.
9.1. Безопасность
Безопасность заключает в себе много вопросов системы «присутствия».
Абоненты могут не желать показывать тот факт, что они подписаны к некоторым пользователям.
Пользователи могут не желать показывать, что у них есть принятые подписки от некоторых пользователей.
Уведомления (и результаты выборки) могут содержать чувствительные данные, которые не следует показывать кому либо, кроме абонента.
Безопасность обеспечивают посредством комбинации сквозного шифрования и последовательного шифрования. Средства и способы сквозного шифрования обеспечивают расширяемые услуги безопасности, блокируют атаки, вовлекающие в себя анализ трафика, и скрывают все аспекты сообщений о «присутствии». Однако они действуют на основании транзитивности достоверности и могут приводить к тому, что содержимое сообщения будет показано прокси-серверу. Последовательные способы не требуют транзитивности достоверности и показывают информацию только требуемому получателю. Однако последовательное шифрование не может скрыть всю информацию, и уязвимо для анализа трафика. Строгая сквозная аутентификация и шифрование требуют также, чтобы оба участника имели открытые ключи, что не является обычным случаем. Таким образом, необходимы объединение обоих способов для услуг полной безопасности.
SIP допускает любую схему сквозного шифрования. Рекомендуют, чтобы между сетевыми серверами (прокси-сервер с прокси-сервером, прокси-сервер с серверами переадресации) был использован транспортный режим ESP [11] (ПКУ, ESP) для шифрования полного сообщения. Между UAC и его локальным прокси-сервером рекомендуют TLS [12]. Подобным образом следует использовать TLS между сервером «присутствия» и ПАП.
Сервер «присутствия» может определить, поддержана ли TLS принимающим клиентом, на основании параметра транспорта в заголовке Contact в его регистрации. Если эта регистрация содержит лексему «tls» в качестве транспорта, то подразумевает, что ПАП поддерживает TLS.
Более того, заголовку Contact позволяют в запросе SUBSCRIBE содержать TLS в качестве транспорта. Заголовок Contact используют для маршрутизации последовательных сообщений между парами объектов. Он определяет адрес и транспорт, используемый для связи с пользовательским агентом. Даже несмотря на то, что TLS может быть использован между абонентом и его локальным прокси-сервером, помещение этого параметра в заголовок Contact означает, что TLS может быть также использован последовательно для генерирования уведомлений после того, как начальное сообщение SUBSCRIBE было успешно маршрутизировано. Это обеспечит услуги последовательной безопасности и аутентификации с низкими издержками для прокси-сервера.
Шифрование SIP может быть использовано последовательно для передачи обоих запросов SUBSCRIBE и NOTIFY. SIP поддерживает шифрование на основании PGP (Pretty Good Privacy, Алгоритм «надежной конфиденциальности», АНК), которое не требует создания ключа сеанса для шифрования сообщений в пределах данной подписки (в основном, новый ключ сеанса создают как часть шифрования АНК). Недавно начата работа по применению S/MIME [13] для SIP.
9.2. Целостность и подлинность сообщения
Для получателя сообщения важно гарантировать, что содержимым сообщения является фактически то, что было послано отправителем и что получатель сообщения способен определить, кто действительно является отправителем. Это применяют к обоим запросам и ответам для SUBSCRIBE и NOTIFY. В SIP это поддерживают посредством последовательной аутентификации и целостности сообщения. SIP обеспечивает аутентификацию и целостность на основании АНК (обеих подписей запрос/ответ и открытого ключа), и аутентификации базовых http и комбинированных сообщений. Базовые http не рекомендуют.
9.3. Исходящая аутентификация
Когда для передачи исходящих сообщений используют локальные прокси-серверы, то рекомендуют аутентификацию прокси-сервером. Полезно проверять идентичность отправителя и предотвращать в сети отправителя попытки несанкционированного доступа и ненужную рассылку.
9.4. Предотвращение повторения
Для предотвращения повторения старых подписок и уведомлений все подписанные запросы SUBSCRIBE и NOTIFY и ответы должны содержать заголовок Date (Дата), маскированный подписью сообщения. Любое сообщение с датой, более ранней, чем несколько прошедших минут, или более поздней, чем несколько минут в будущем, следует отвергать.
Более того, все подписанные запросы SUBSCRIBE и NOTIFY и ответы должны содержать заголовки Call-ID и CSeq, маскированные подписью сообщения. Пользовательский агент и сервер «присутствия» могут хранить перечень значений Call-ID, и для каждого виден наивысший CSeq в пределах этого Call-ID. Любое сообщение, которое поступает для существующего Call-ID и у которого CSeq ниже, чем видимый до сих пор наивысший, отвергают.
Наконец, можно использовать аутентификацию запрос/ответ (комбинированных сообщений http или АНК) для предотвращения атак повторения.
9.5. Отказ атакам сервиса
Отказ атакам сервиса является критической задачей для открытого, междоменного протокола «присутствия». В настоящем разделе обсуждают несколько возможных атак и предпринятые шаги для их предотвращения.
9.5.1. Массовые атаки посредством ложных контактов
К сожалению, «присутствие» является хорошим кандидатом для массовых атак из-за своих свойств к усилению. Одиночное сообщение SUBSCRIBE может порождать почти бесконечный поток уведомлений так длительно, как сможет позволить соответствующий динамический источник данных «присутствия». Таким образом, простым способом загрузки атаки является посылка подписок к большому количеству пользователей, и помещения адреса цели в заголовке Contact (в котором посылают уведомления пользователям).
Единственным надежным способом предотвращения таких атак являются аутентификация и авторизация. Есть надежда, что конечные пользователи не будут принимать подписок от случайных нераспознанных пользователей. Также, программное обеспечение клиента «присутствия» может быть программировано так, чтобы предупреждать пользователя о случаях, когда заголовок Contact в SUBSCRIBE относится к домену, который не совпадает с находящимся в поле From (который идентифицирует абонента).
Отметим также, что как описано в [3], если NOTIFY не подтвержден или не желателен, то подписку, которая его сгенерировала, удаляют. Это устраняет свойства усиления для поставки ложных адресов Contact.
10. Примерные последовательности сообщений
Последующие подразделы представляют примерные последовательности сообщений для дополнительного пояснения поведения протокола.
10.1. Подписка клиента к клиенту с изменением состояний «представительности»
Эта последовательность вызовов иллюстрирует подписки и уведомления, которые не вовлекают сервер «присутствия».
«Контролер» осуществляет подписку к «представительности», и подписка принята, приводя к ответу «202 Принято». «Представительность» последовательно изменяет состояние (на телефоне), приводя к новому уведомлению. Последовательность оканчивается при отмене «контролером» подписки.
Подробности сообщения
F1 SUBSCRIBE «контролер» -> «представительность»
SUBSCRIBE SIP:presentity@pres/example.com SIP/2.0
Via: SIP/2.0/DP watcherhost.example.com:5060
From: User <pres:user@example.com>
To: Resource <pres:presentity@example.com>
Call-ID: 3248543@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Expires: 600
Accept: application/xpidf+xml
Event: presence
Contact: SIP:user@watcherhost.example.com
F2 «202 Принято» «представительность» -> «контролер»
SIP/2.0 202 Accepted
Via: SIP/2.0/DP watcherhost.example.com:5060
From: User <pres:user@example.com>
To: Resource <pres:presentity@example.com>;tag=88a7s
Call-ID: 3248543@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Event: presence
Expires: 600
Accept: application/xpidf+xml
Contact: SIP:presentity@pres.example.com
F3 NOTIFY «представительность» -> «контролер»
NOTIFY SIP:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pres.example.com:5060
From: Resource <pres:presentity@example.com>;tag=88a7s
To: User <pres:user@example.com>
Call-ID: 3248543@watcherhost.example.com
CSeq: 1 NOTIFY
Event: presence
Content-Type: application/xpidf+xml
Content-Length: 120
<?xml version="1.0"?>
<presence entityInfo="pres:presentity@example.com">
<tuple destination="SIP:presentity@example.com" status="open"/>
</presence>
F4 «200 Успешно» «контролер» -> «представительность»
SIP/2.0 200 OK
Via: SIP/2.0/UDP pres.example.com:5060
From: Resource <pres:presentity@example.com>
To: User <pres:user@example.com>
Call-ID: 3248543@watcherhost.example.com
CSeq: 1 NOTIFY
F5 NOTIFY «представительность» -> «контролер»
NOTIFY SIP:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pres.example.com:5060
From: Resource <pres:presentity@example.com>
To: User <pres:user@example.com>
Call-ID: 3248543@watcherhost.example.com
CSeq: 2 NOTIFY
Event: presence
Content-Type: application/xpidf+xml
Content-Length: 120
<?xml version ="1.0"?>
<presence entityInfo="pres:presentity@example.com">
<tuple destination="SIP:presentity@example.com" status="closed"/>
</presence>
F6 «200 Успешно» «контролер» -> «представительность»
SIP/2.0 200 OK
Via: SIP/2.0/UDP pres.example.com:5060
From: Resource <pres:presentity@example.com>
To: User <pres:user@example.com>
Call-ID: 3248543@watcherhost.example.com
CSeq: 2 NOTIFY
F7 SUBSCRIBE «контролер» -> «представительность»
SUBSCRIBE SIP:presentity@pres.example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <pres:user@example.com>
To: Resource <pres:presentity@example.com>
Call-ID: 3248543@watcherhost.example.com
Event: presence
CSeq: 2 SUBSCRIBE
Expires: 0
Accept: application/xpidf+xml
Contact: SIP:user@watcherhost.example.com
F8 «202 Принято» «представительность» -> «контролер»
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <pres:user@example.com>
To: Resource <pres:presentity@example.com>
Call-ID: 3248543@watcherhost.example.com
Event: presence
CSeq: 2 SUBSCRIBE
Expires: 0
10.2. Сервер «присутствия» с уведомлениями клиента
Эта последовательность вызовов показывает вовлечение сервера «присутствия» в обработку подписок. По этому сценарию клиенту указано, что он будет обрабатывать подписки и, таким образом, уведомления. Последовательность сообщений показывает изменение состояния «присутствия» клиентом и отмену подписки «контролером».
Подробности сообщения
Fl REGISTER ПАП -> сервер
REGISTER SIP:example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: <SIP:resource@example.com>
From: <SIP:resource@example.com>
Call-ID: 2818@pua.example.com
CSeq: 1 REGISTER
Contact: <SIP:id@pua.example.com>;methods="MESSAGE"
;description="open"
Contact: <SIP:id@pua.example.com>;methods="SUBSCRIBE"
Expires: 600
F2 «200 Успешно» сервер -> ПАП
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To: <SIP:resource@example.com>
From: <SIP:resource@example.com>
Call-ID: 2818@pua.example.com
CSeq: 1 REGISTER
Contact: <SIP:id@pua.example.com>;methods="MESSAGE"
;description="open"
Contact: <SIP:id@pua.example.com>;methods="SUBSCRIBE" Expires: 600
F3 SUBSCRIBE «контролер» -> сервер
SUBSCRIBE SIP:resource@example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <pres:user@example.com>
To: Resource <pres:resource@example.com>
Call-ID: 32485@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Expires: 600
Event: presence
Accept: application/xpidf+xml
Contact: SIP:user@watcherhost.example.com
F4 SUBSCRIBE сервер -> ПАП
SUBSCRIBE SIP:id@pua.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <pres:user@example.com>
To: Resource <pres:resource@example.com>
Call-ID: 32485@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Event: presence
Expires: 600
Accept: application/xpidf+xml
Contact: SIP:user@watcherhost.example.com
F5 «202 Принято» ПАП -> сервер
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP server.example.com:5060
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <pres:user@example,com>
To: Resource <pres:resource@example.com>;tag=ffd2
Cal1-ID: 32485@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Event: presence
Expires: 600
F6 «200 Успешно» сервер -> «контролер»
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP watcherhost.example.com:5060
From: User <pres:user@example.com>
To: Resource <pres:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Event: presence
Expires: 600
F7 NOTIFY ПАП -> «контролер»
NOTIFY SIP:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: User <pres:user@example.com>
From: Resource <pres:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq: 1 NOTIFY
Event: presence
Content-Type: application/xpidf+xml
Content-Length: 120
<?xml version="1.0"?>
<presence entityInfo="pres:resource@example.com">
<tuple destination="im:resource@example.com" status="open"/>
</presence>
F8 «200 Успешно» «контролер» -> ПАП
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To: User <pres:user@example.com>
From: Resource <pres:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq: 1 NOTIFY
F9 REGISTER ПАП -> сервер
REGISTER SIP:example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: <SIP:resource@example.com>
From: <SIP:resource@example.com>
Call-ID: 2818@pua.example.com
CSeq: 2 REGISTER
Contact: <SIP:id@pua.example.com>;methods="MESSAGE"
;description="busy"
Contact: <SIP:id@pua.example.com>;methods="SUBSCRIBE" Expires: 600
F10 «200 Успешно» сервер -> ПАП
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To: <SIP:resource@example.com>
From: <SIP:resource@example.com>
Call-ID: 2818@pua.example.com
CSeq: 2REGISTER
Contact: <SIP:id@pua.example.com>;methods="MESSAGE"
;description="busy"
Contact: <SIP:id@pua.example.com>;methods="SUBSCRIBE" Expires: 600
Fll NOTIFY ПАП -> «контролер»
NOTIFY SIP:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: User <pres:user@example.com>
From: Resource <pres:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq: 2 NOTIFY
Event: presence
Content-Type: application/xpidf+xml
Content-Length: 120
<?xml version="1.0"?>
<presence entityInfo="pres:resource@example.com">
<tuple destination ="im:resource@example.com" status="busy"/>
</presence>
F12 «200 Успешно»«контролер» -> ПАП
SIP/2.0 200 OK
Via: SIP/2.0/UDP pua.example.com:5060
To: User <pres:user@example.com>
From: Resource <pres:resource@example.com>;tag=ffd2
Call-ID: 32485@watcherhost.example.com
CSeq: 2 NOTIFY
10.3. Уведомления сервера «присутствия»
Эта последовательность сообщений иллюстрирует, как сервер «присутствия» может быть ответственным за посылку уведомлений для «представительности». Сервер «присутствия» будет это делать, если «представительность» не посылала регистрацию, указывающую заинтересованность в обработке подписок. В этой последовательности предполагают, что «контролер» был предварительно авторизован для подписки к этому ресурсу на сервере.
Подробности сообщения
Fl SUBSCRIBE«контролер» -> сервер
SUBSCRIBE SIP:resource@example.com SIP/2.0
Via: SIP/2.0/UDP watcherhost.example.com:5060
To: <pres:resource@example.com>
From: <pres:user@example.com>
Call-ID: 2010@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Event: presence
Accept: application/xpidf+xml
Contact: <SIP:user@watcherhost.example.com>
Expires: 600
F2 «202 Успешно»сервер -> «контролер»
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP watcherhost.example.com:5060
To: <pres:resource@example.com>;tag=ffd2
From: <pres:user@example.com>
Call-ID: 20l0@watcherhost.example.com
CSeq: 1 SUBSCRIBE
Event: presence
Expires: 600
Contact: SIP:example.com
F3 NOTIFYсервер -> «контролер»
NOTIFY SIP:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
From: <pres:resource@example.com>;tag=ffd2
To: <pres:user@example.com>
Call-ID: 2010@watcherhost.example.com
Event: presence
CSeq: 1 NOTIFY
Content-Type: application/xpidf +xml
Content-Length: 120
<?xml version="1.0"?>
<presence entityInfo="pres:resource@example.com">
<tuple destination="im:resource@example.com" status="open"/>
</presence>
F4 «200 Успешно»
SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
From: <pres:resource@example.com>;tag=ffd2
To: <pres:user@example.com>
Call-ID: 2010@watcherhost.example.com
CSeq: 1 NOTIFY
F5 REGISTER
REGISTER SIP:example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com:5060
To: <SIP:resource@example.com>
From: <SIP:resource@example.com>
Call-ID: 110@pua.example.com
CSeq: 2 REGISTER
Contact: <SIP:id@pua.example.com>/methods="MESSAGE"
;description="Away from keyboard"
Expires: 600
F6 «200 Успешно»
Via: SIP/2.0/UDP pua.example.com:5060
To: <SIP:resource@example.com>
From: <SIP:resource@example.com>
Call-ID: 110@pua.example.com
CSeq: 2 REGISTER
Contact: <SIP:id@pua.example.com>;methods="MESSAGE"
; description="Away from keyboard"
; expires=600
F7 NOTIFY
NOTIFY SIP:user@watcherhost.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com:5060
From: <pres:resource@example.com>;tag=ffd2
To: <pres:user@example.com>
Call-ID: 2010@watcherhost.example.com
CSeq: 2 NOTIFY
Event: presence
Content-Type: application/xpidf+xml
Content-Length: 120
<?xml version ="1.0"?>
<presence entityInfo="pres:resource@example.com">
<tuple destination="im:resource@example.com" status="Away from keyboard"/>
</presence>
F8 «200 Успешно»
SIP/2.0 200 OK
Via: SIP/2.0/UDP server.example.com:5060
From: <SIP:resource@example.com>;tag=ffd2
To: <pres:user@example.com>
Call-ID: 20l0@watcherhost.example.com
CSeq: 2 NOTIFY
11. Открытые вопросы
Нижеследующее является перечнем известных открытых вопросов:
В этом проекте рекомендуют, что поля То и From наполняют предпочтительнее URI «присутствия», чем URI SIP. Это разумно? Будет ли это вести к несовместимости в прокси-сервере? Существуют ли какие либо вопросы с ОПОНС, если используют формат URL SIP? Это зависит от того, какие компоненты сообщения подписаны в ОПОНС.
Ограничения на частоту NOTIFY: это желательно? Как увеличить значение? 5 секунд является произвольным значением.
Слияние данных «присутствия» от множественных ПА было удалено. Это хорошо?
Помещение URI НС в заголовок Contact (в) REGISTER: это хорошо? Что это означает?
Процесс миграции подписок от сервера «присутствия» к ПАП, вероятно, не работает в случае, когда подписка обновляет используемые заголовками метки и Route. Итак, есть выбор. Либо миграцию запрещают и поддерживают подписки, ориентированные на разветвленные запросы, либо миграцию разрешают, и отсутствуют метки или Route, ассоциированных с подписками.
Преобразование URL SIP обратно к URL «представительности».
Шлюзы «SIP к ОПОНС» и «ОПОНС к SIP» не являются не запоминающими состояние, поскольку необходимо поддерживать Route, Call-ID, CSeq и другие параметры. Возможно, следует просить ОПОНС определить значение лексемы, которое посылают в запросе ОПОНС и принимают в ответе ОПОНС. Поможет ли это?
Необходимо описать, как получать поля Contact из REGISTER и создавать документ «присутствия». Очевидно то, что адресы Contact не работают в данном случае непосредственно; вероятно есть желание поместить адрес записи, иначе вызовы могут не пройти через прокси-сервер.
12. Изменения относительно (версии) -00
Документ был полностью переписан для отражения изменений от «товара на продажу и учебного документа» к более формальному описанию протокола. Документ также был изменен для согласования с архитектурой событий в SIP и с ОПОНС. Конкретными изменениями протокола в результате этой переделки являются:
Заголовок Event не должен быть использован в запросах SUBSCRIBE и NOTIFY.
Сообщение SUBSCRIBE может единственно иметь одиночный заголовок Contact. В -00 позволялось для более чем одного.
Заголовки From и То могут содержать идентификаторы URI «присутствия».
Поле Request-URI может содержать URI «присутствия».
На подписки отвечают с 202, если они являются ожидающими или принятыми.
Документы «присутствия» не возвращают в теле ответа (на) SUBSCRIBE. Предпочтительнее их посылают в отдельном NOTIFY. Это более ясно разделяет подписку и уведомление и предписано приведением в соответствие с ОПОНС.
Аутентификация теперь обязательна на ПА. Авторизация теперь обязательна на ПА.
Фиктивный NOTIFY посылают для ожидающих или отвергнутых подписок.
Было введено ограничение на частоту уведомлений.
Было удалено слияние данных «присутствия».
Абонент отвергает уведомления, принятые с метками, которые не совпадают с такими же в ответе 202 на SUBSCRIBE. Это означает, что только ПА будут содержать состояние подписки для конкретного абонента для конкретной «представительности».
URI НС допускают в Contact в REGISTER.
Определены отображения ОПОНС.
Для обхода брандмауэра рекомендуют постоянные связи.
Получение авторизации
Когда подписка прибывает на ПА, то подписка требует быть авторизованной «представительностью». В некоторых случаях «представительность» возможно уже обеспечила авторизацию заранее. Однако во многих случаях абонент не является предварительно авторизован. В таком случае ПА необходимо запросить «представительность» для авторизации.
Чтобы сделать это, определена неявная подписка на ПА. Такая подписка предназначена для виртуальной «представительности», которая является "множеством подписок для «представительности» X", и абонентом такой виртуальной «представительности» является собственно Х. Всякий раз, когда подписка принята для Х, виртуальная «представительность» изменяет состояние для отображения новой подписки для Х. Изменения состояния происходят для подписок, которые подтверждены, и для тех, который является ожидающими. В результате этого, когда прибывает подписка, которой необходима авторизация, то происходит изменение состояния виртуальной «представительности», чтобы указать ожидающую подписку. Полное состояние виртуальной «представительности» затем посылают к абоненту (к самой «представительности»). Таким образом, пользователь «позади» такой «представительности» может видеть, что присутствуют ожидающие подписки. Затем он может использовать некоторые, не относящиеся к SIP, средства для установления политики на сервере относительно такого нового пользователя. Такую политику затем используют для того, чтобы либо принять, либо отвергнуть подписку.
Последовательность вызовов для этого показана на Фиг.3.
В том случае, когда «представительность» не является интерактивной, задача также прямая. Когда пользователь осуществляет регистрацию в клиенте «присутствия», то он может извлечь состояние виртуальной «представительности» для Х, проверить на ожидающие подписки и для каждой из них загрузить новую политику, которая указывает соответствующее действие, которое следует предпринять.
Формат данных для представления состояния такой виртуальной «представительности» может быть найден в [14].
А. Благодарности
Следует поблагодарить следующих лиц за их поддержку и комментарии по настоящему проекту:
Rick Workman, Nortel
Adam Roach, Ericsson
Sean Olson, Ericsson
Billy Biggs, University of Waterloo
Stuart Barkley, UUNet
Mauricio Arango, SUN
Richard Shockey, Shockey Consulting LLC
Jorgen Bjorkner, Hotsip
Henry Sinnreich, MCI Worldcom
Ronald Akers, Motorola
B.Адреса авторов
Jonathan Rosenberg
Фиг.3. Диаграмма последовательности сообщений для интерактивной авторизации
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com
Dean Willis
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Piano, Texas 75024
email: dwillis@dynamicsoft.com
Robert Sparks
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Piano, Texas 75024
email: rsparks@dynamicsoft.com
Ben Campbell
5100 Tennyson Parkway
Suite 1200
Piano, Texas 75024
email: bcampbell@dynamicsoft.com
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
email: schulzrinne@cs.columbia.edu
Jonathan Lennox
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
emai1: lennox@cs.Columbia.edu
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
email: huitema@microsoft.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
email: bernarda@microsoft.com
David Gurle Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 email: dgurle@microsoft.com
David Oran
Cisco Systems
170 West Tasman Dr.
San Jose, CA 95134
email: oran@cisco.com
С. Библиография
[1] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and instant messaging," Request for Comments 2778, Internet Engineering Task Force, Feb. 2000.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999.
[3] A. Roach, "Event notification in SIP," Internet Draft, Internet Engineering Task Force, Oct. 2000. Work in progress.
[4] D. Crocker et al., "A common profile for instant messaging (CPIM)," Internet Draft, Internet Engineering Task Force, Nov. 2000. Work in progress.
[5] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman, "DIAMETER base protocol," Internet Draft, Internet Engineering Task Force, Sept. 2000. Work in progress.
[6] C. Rigney, S. Willens, A. Rubens, and W. Simpson, "Remote authentication dial in user service (RADIUS)," Request for Comments 2865, Internet Engineering Task Force, June 2000.
[7] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, and A. Sastry, "The COPS (common open policy service) protocol," Request for Comments 2748, Internet Engineering Task Force, Jan. 2000.
[8] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and callee capabilities," Internet Draft, Internet Engineering Task Force, July 2000. Work in progress.
[9] J. Rosenberg, D. Drew, and H. Schulzrinne, "Getting SIP through firewalls and NATs," Internet Draft, Internet Engineering Task Force, Feb. 2000. Work in progress.
[10] J. Rosenberg and H. Schulzrinne, "SIP traversal through enterprise and residential NATs and firewalls," Internet Draft, Internet Engineering Task Force, Nov. 2000. Work in progress.
[11] S. Kent and R. Atkinson, "IP encapsulating security payload (ESP), "Request for Comments 2406, Internet Engineering Task Force, Nov. 1998.
[12] T. Dierks and C. Allen, "The TLS protocol version 1.0, "Request for Comments 2246, Internet Engineering Task Force, Jan. 1999.
[13] B. Ramsdell and Ed, "S/MIME version 3 message specification, "Request for Comments 2633, Internet Engineering Task Force, June 1999.
[14] J. Rosenberg et al., "An XML based format for watcher information," Internet Draft, Internet Engineering Task Force, June 2000. Work in progress.
Оглавление
1. Введение
2. Определения
3. Обзор принципа действия
4. Наименование
5. Пакет событий для присутствия
5.1. Имя пакета
5.2. Тела SUBSCRIBE
5.3. Время завершения
5.4. Тела NOTIFY
5.5. Обработка требований на АП
5.6. Генерирование уведомлений
5.7. Ограничения на частоту NOTIFY
5.8. Поведение для обновления
6. Публикация
6.1. Миграция функции АП
7. Отображение на CPIM
7.1. Отображение SIP в CPIM
7.2. Отображение CPIM в SIP
8. Брандмауэр и прохождение ПСА
9. Рассмотрения безопасности
9.1. Безопасность
9.2. Целостность и подлинность сообщения
9.3. Исходящая аутентификация
9.4. Предотвращение повторения
9.5. Отказ атакам сервиса
9.5.1. Массовые атаки посредством ложных контактов
10. Примерные последовательности сообщений
10.1. Подписка клиента к клиенту с изменением состояний «представительности»
10.2. Сервер «присутствия» с уведомлениями клиента
10.3. Уведомления сервера «присутствия»
11. Открытые вопросы
12. Изменения относительно (версии) -00
А. Благодарности
В. Адреса авторов
С. Библиография
Группа по техническим спецификациям аспектов услуг и систем;
Архитектура для сети с общим IP
(3П ТО 23.922 версия 1.0.0)
Valbonne - FRANCE
Тел.:+33 4 92 94 42 00 Факс.:+33 4 93 65 47 16
Интернет
Содержание
Предисловие
1. Область назначения
2. Ссылки
3. Определения и сокращения
3.1. Определения
3.2. Перечень сокращений
4. Требования
4.1. Общие положения
4.1.1. Общие требования
4.2. Возможности услуг
4.2.1. Общие положения
4.2.2. Основные требования для платформ услуг и приложений
4.3. Схемы нумерации
4.4. Терминалы по Версии 99
4.5. Вопросы радиосвязи
4.6. Межсетевой обмен
4.7. Управление мобильностью
4.8. Роуминг
4.9. Передача обслуживания
4.9.1. Категории передач обслуживания
4.9.2 Общее определение
4.9.3. Общие требования
4.9.4. Требования к ПС
4.9.5. Требования к РЗС
4.10. Управление вызовом и роуминг
4.11. Безопасность
5. Архитектура СОПНПО на основе ОИП
5.1. Эталонная архитектура
5.1.1. Эталонная архитектура - Вариант 1
5.1.2. Эталонная Архитектура - Вариант 2
5.1.3. Что является границей сети
5.2. Новые функциональные элементы
5.2.1. Функция Управления Состоянием Вызова (ФУСВ)
5.2.2. Домашний сервер абонента (ДСА)
5.2.3. Функция транспорта межсетевой сигнализации (Т-МСС)
5.2.4. Функция роуминга межсетевой сигнализации (Р-МСС)
5.2.5. Составной шлюз
5.2.6. Функция управления медиа-шлюзом (ФУМШ)
5.2.7. Функция медиа-шлюза (ФМШ)
5.2.8. Функция мультимедиа-ресурса (ФМР)
5.2.9. Сервер ЦКПС
5.2.10. Межсетевой сервер ЦКПС (МЦКПС)
5.3. Описание опорных точек
5.3.1. Опорная Точка Cx (ДСА - ФУСВ)
5.3.2. Опорная Точка Gm (ФУСВ - ПО)
5.3.3. Опорная точка Мс (ФУМШ - МШ)
5.3.4. Опорная точка Mh ( ДСА - Р-МСС)
5.3.5. Опорная точка Мм (ФУСВ - сети IP мультимедиа)
5.3.6. Опорная точка Mr (ФУСВ - ФМР)
5.3.7. Опорная точка Ms (ФУСВ - Р-МСС)
5.3.8. Опорная точка Mw (ФУСВ - ФУСВ)
5.3.9. Опорные точки Nc (Сервер ЦКПС - Сервер МЦКПС)
5.3.10. Опорные точки Nb (МШ-МШ)
5.3.11. От УУОН к приложениям и услугам
5.4. Использование МАР/САР - Стек Протокола ниже МАР/САР - Общие рассмотрения
6. КО (Качество обслуживания)
7. Передача обслуживания
7.1. Перемещение ОРСК внутри IP сети УМТС R00
7.1.1. Требуемая поддержка внутри РРЗС
7.1.2. Передача обслуживания от ОИП УНСРД к ОИП РРЗС
7.2. Перемещение ОРСК/ Передача обслуживания между доменом ОИП и доменом КК/GSM
7.2.2. Решение с ФУСВ, поддерживающей МАР/Е
7.2.3. Межсистемная передача обслуживания с использованием ФМЭП
7.3. Области дальнейшего исследования
8. Вопросы радиосвязи
8.1. Общие положения
8.2. Оптимизация линии воздушной радиосвязи для IP реального времени
8.2.1. Введение
8.2.2. Адаптация пользовательского уровня
8.2.3. Применение к сети ОИП
8.2.4. Выводы
9. Управление Вызовом
9.1. Терминология для управления вызовом
9.2. Предположения
9.3. Роуминг внутри сетей ОИП
9.3.1. Модель вызова
9.3.2. Сценарий 1, Традиционная Модель
9.3.3. Сценарий 2
9.3.4. Сценарий 1: Потоки информации для проверки правильности
9.3.5. Сценарий 2: Потоки информации для проверки правильности
9.4. Роуминг к другим сетям
9.4.1. Процедура роуминга для сетей R00
9.4.2. Роуминг с перекрытием
9.5. Открытые вопросы
10. Влияние платформы (реализации)услуг
10.1. Архитектура услуг ПП3П по Версии 2000
10.2. Услуги на основании ИС
10.2.1. Интерфейс между действующей ПУО и сетевыми элементами на основании INAP
10.2.2. Новый открытый интерфейс между действующими ПУО и сетевыми элементами R00
10.3. Вопросы для дополнительной проработки
11. Безопасность
12. План работ
12.1. Промежуточные сроки для Версии 00
12.1.1. Промежуточные сроки версии 00
12.1.2. Подробный план деятельности
История документа
Предисловие
Настоящий технический отчет разработан ПП3П.
Содержание настоящего документа является предметом продолжающейся работы в рамках ГТС (Группы по техническим спецификациям, TSG) и может изменить последующее формальное утверждение ГТС. Если ГТС изменит содержимое настоящих технических спецификаций, то ГТС повторно выпустит версию с указанием даты изменения версии и с таким номером версии, как показано ниже:
Версия x.y.z
При этом:
x - первая цифра:
1 - представлена ГТС для информации;
2 - представлена ГТС для утверждения;
3 - указывает утвержденный ГТС документ в стадии контроля изменений.
y - вторую цифру увеличивают для всех изменений содержимого, например, технических расширений, корректур, обновлений, и т.д.
z - третью цифру увеличивают в тех случаях, когда редактируют изменения, уже включенные в состав спецификации.
1. Областьназначения
Настоящий технический отчет предлагает архитектуру, которая обеспечивает вариант архитектуры ОИП для версии 00. назначением технического отчета является:
- Идентификация ключевых вопросов и воздействий на продолжаемую ПП3П работу, которые требует разрешения и
- Предложение высокоуровневого плана работ по выполнению версии 00 стандарта УМТС на основе ОИП для того, чтобы предусмотреть такой вариант архитектуры в пределах Версии 2000.
2. Ссылки
Нижеследующие документы содержат положения, которые посредством ссылок в тексте образуют обеспечение настоящего документа.
Ссылки либо конкретизированы (идентифицированы датой опубликования, номером редакции, номером версии, и т.д.), либо не конкретизированы.
Для конкретизированной ссылки последующие ревизии не применяют.
Для ссылки, которая не конкретизирована, применяют последнюю версию.
Ссылку на ETS, которая не конкретизирована, следует также относить к последним версиям, опубликованным в качестве EN с тем же номером.
[1] TS 22.101 Service principles
[2] TS 23.121 Architectural Requirements for Release 99
[3] TS 22.121 The Virtual Home Environment
[4] TS 23.002 Network architecture
[5] "Compressing TCP/IP Headers for Low-Speed Serial Links", IETF RFC 1144, V. Jacobson
3. Определения и сокращения
3.1. Определения
Для целей настоящего документа применяют следующие термины и определения.
Существующая услуга: услуга, поддерживаемая в Версии 99 и в более ранних версиях как для GSM, так и для УМТС (UMTS, Универсальная мобильная телекоммуникационная система).
All IP core network - Базовая сеть с общим IP, или сеть, полностью основанная на межсетевом, или Интернет, протоколе (ОИП): базовая сеть по версии 2000, которая использует IP для транспорта всех пользовательских данных и сигнализации.
ERAN (РРЗС) определен как развернутый GSM ОБС, поддерживающий схемы модуляции EDGE на основе 200 кГц и пакетные услуги реального времени.
3.2. Перечень сокращений
Для целей настоящего документа применяют следующие сокращения:
<Сокращение> <Объяснение>
2G, second generation - (Система) второго поколения, 2П
3G, third generation - (Система) третьего поколения, 3П
AMR, Adaptive Multi Rate - Адаптивная многоскоростная, АМС
AS, Application Server - Сервер приложений, СП
BSC, Base Station Controller - Контроллер базовой станции, КБС
BTS, Base Station - Базовая станция, БС
CAMEL, Customized Applications for Mobile Network Enhanced Logic - Специализированные приложения для расширенной логики подвижных сетей, СПРЛПС
CAP, CAMEL Application Part - Подсистема специализированных приложений, ПСП
CC, Call Control - Управление вызовом, УВ
CCF, Call Control Function - Функция управления вызовом, ФУВ
CN, Core Network - Базовая сеть, БС
CS Circuit Switched - С коммутацией каналов, КК
CSCF, Call State Control Function - Функция управления состоянием вызова, ФУСВ
CSE, CAMEL Service Environment - Среда услуг СПРЛПС, СУС
DN, Directory Number - Справочный номер, СН
DNS, Directory Name Server - Сервер справочных имен, ССИ
EDGE, Enhanced Data for GSM - Расширенные данные для Глобальной системы подвижной связи, РДГС
EGPRS, Enhanced GPRS - Расширенные услуги общего назначения для пакетной радиосвязи, РУОНПР
FFS, For Further Study - Для дальнейшего исследования, ДДИ
GGSN, Gateway GPRS Support Node - Узел поддержки межсетевых УОНПР, УПМУ
GMSC, Gateway MSC - Шлюз ЦКПС, ШЦКПС
GPRS, General Packet Radio Service - Услуги общего назначения (для) пакетной радиосвязи, УОНПР
GSN, GPRS Support Node - Узел поддержки УОНПР, УПУ
GTP, GPRS Tunneling Protocol - Протокол туннелирования, УОНПР
H-CSCF, Home CSCF - Домашняя ФУСВ, ФУСВ-Д
HN, Home Network - Домашняя сеть, ДС
HSS, Home Subscriber Server - Домашний сервер абонента, ДСА
ICGW, Incoming Call Gateway - Шлюз входящего вызова, ШВВ
IN, Intelligent Network - Интеллектуальная сеть, ИС
INAP IN Application Part - Прикладная подсистема ИС, ППИС
IP, Internet Protocol - Межсетевой протокол, ИП
ISDN, Integrated Services Digital Network - Цифровая сеть с интеграцией услуг, ЦСИУ
ISP, Internet Service Provider - Поставщик услуг Интернет, ПУИ
ISUP, ISDN User Part - пользовательская подсистема ЦСИУ, ППИУ (пользовательская подсистема интеграции услуг)
LAN, Local Area Network - Локальная сеть, ЛВС
LN, Logical Name - Логическое имя, ЛИ
MAHO, Mobile Assisted Handover - Автоматическая передача вызовов по сотам, АПВС
MAP Mobile Application Part - Подсистема подвижной связи, ППС
MCU, Media Control Unit - Блок управления средой, БУС
MexE, Mobile Execution Environment - Исполнительная среда подвижной связи, ИСПС
MGCF, Media Gateway Control Function - Функция управления медиа-шлюзом, ФУМШ
MGW Media Gateway - Медиа-шлюз, МШ
MM, Mobility Management - Управление мобильностью, УМ
MO, Mobile Originated - вызов, Отправленный подвижным абонентом, ОПА
MRF Media Resource Function - Функция медиа-ресурса, ФМР
MSC Mobile Switching Center - Центр коммутации подвижной связи, ЦКПС
MT, Mobile Terminated/Terminal - Подвижный терминал, ПТ
NPA, Numbering Plan Area - Зона номерного плана, ЗНП
O&M, Operations and Maintenance - Эксплуатация и техническое обслуживание, ЭиТО
ODB, Operator Determined Barring - Запрет вызова по определению оператора, ЗВОО
OSA, Open Service Architecture - Архитектура открытых услуг, АОУ
PCU, Packet Control Unit - Блок управления пакетами, БУП
PDP, Packet Data Protocol - Протокол передачи пакетных данных
PDU, Packet Data Unit - Блок пакетных данных, БПД
PS, Packet Switched - С коммутацией пакетов, КП
PSTN, Public Switched Telephony Network - Коммутируемая телефонная сеть общего назначения, КТСОН
QoS, Quality of Service - Качество обслуживания, КО
R00 Release 2000 - Версия 2000, R00
R99 Release 1999 - Версия 1999, R99
RA, Routing Area - Зона маршрутизации, ЗМ
RAN, Radio Access Network - Сеть радиодоступа, СРД
RLC/MAC, Radio Link Control/Media Access Control - Управление радиолинией/Управление доступом к среде, УРЛ/УДС
RNC Radio Network Controller - Радиосетевой контроллер, РСК
R-SGW, Roaming Signaling Gateway - Шлюз сигнализации роуминга, ШС-Р
RTP, Real Time Protocol - Протокол реального времени
SAT, SIM Application Toolkit - Инструментальные средства разработки приложений (сервисный интерфейсный модуль) СПИС
SCF, Service Control Function (IN) and Service Capability Features - Функция управления услугой (ИС), ФУУ; Свойства возможностей услуг, СВУ; (VHE/OSA) - (ВДС/АОУ)
SCP, Service Control Point - Пункт управления обслуживанием, ПУО
S-CSCF, Serving CSCF - ФУСВ-О (обслуживания)
SGSN, Serving GPRS Support Node - Узел услуг общего назначения, УУОН
SIP, Session Initiated Protocol - Протокол инициации (инициированного) сеанса, ПИС
SLA Service Level Agreement - Соглашение об уровне услуг, СУУ
SN, Serving Network - Обслуживающая сеть, ОС
SRNC Serving Radio Network Controller - Обслуживающий радиосетевой контроллер, ОРСК
SSF Service Switching Function - Функция коммутации услуг, ФКУ
TCP Transmission Control Protocol - Протокол управления передачей
ТЕ, Terminal Equipment - Терминальное оборудование, ТО
T-SGW, Transport Signaling Gateway - Шлюз сигнализации транспорта, ШС-Т
UDP User Datagram Protocol - Протокол дейтаграмм пользователя
UE, User Equipment - Пользовательское оборудование, ПО
UMS, User Mobility Server - Сервер пользовательской мобильности, СПМ
UTRAN, UMTS Terrestrial Radio Access Network - Наземная сеть радиодоступа UMTS, НСРДУ
VHE Virtual Home Environment - Виртуальная домашняя среда, ВДС
VLR Visitor Location Register - Визитный регистр местоположения, ВРМ
VoIP, Voice over IP - Речевые данные по IP, РДИП
VPN, Virtual Private Network - Виртуальная частная сеть, ВЧС
WAP, Wireless Application Protocol - Протокол мобильной интерактивной связи с Интернет
WIN Wireless IN (ANSI-41) Беспроводная ИС, БИС
4. Требования
Чтобы для групп TSG-SA2 провести изучение вопросов архитектуры, относящихся к введению полностью основанной на IP (ОИП) архитектуры в рамках УМТС, были сделаны предположения относительно такой архитектуры. TSG-SA1 была приглашена, чтобы проверить и расширить эти требования как часть пакета работ по требованиям для Версии 2000.
4.1. Общие положения
Целью ОИП архитектуры является позволить операторам связи развертывать IP технологию для доставки услуг 3го поколения, то есть, архитектуры, основанной на пакетных технологиях и IP телефонии и предназначенной для услуг, поставляемых одновременно в реальном времени и не в реальном времени. Такую архитектуру следует основывать на эволюции от спецификаций Версии 99 и ей следует быть совместимой с IMT-2000, обеспечивая глобальную мобильность терминала (роуминг) [1].
Сети IP должны обеспечивать беспроводный доступ к подвижному абоненту, который основан на ERAN и УНСРД при использовании базовой сети общего назначения, основанной на эволюции УОНПР. В таком контексте сеть радиодоступа е-УОНПР является основанной на ГСПС сетью, использующей частоту 200 кГц, поддерживающей РДГС и развернутой для поддержки пакетных услуг реального времени. Несмотря на то что РДГС не находится в рамках ПП3П, существуют требования к базовой сети ОИП архитектуры, которые должны быть общими для обеих технологий доступа.
Характеристиками такой сети являются:
Основана на эволюции УОНПР.
Общие сетевые элементы для множества типов доступа, включающих в себя УНСРД и ERAN.
Транспорт пакетов с использованием IP протоколов.
Терминалы, которые допускают применение как IP клиентов.
Поддержка речи, данных, мультимедиа реального времени и услуг посредством одинаковых сетевых элементов.
Настоящий отчет охватывает также поддержку услуг КК на IP технологиях.
Преимущества такого подхода включают в себя:
Возможность предложения эффективно интегрированных услуг посредством использования IP вне зависимости от средств доступа (например, общие свойства, используемые абонентами, осуществляющими доступ через либо традиционную наземную телефонию, либо кабельную, либо беспроводную, либо HIPERPLAN2 (приложение для доступа к мобильным вычислениям) и т.д.).
Совместное действие с обобщенными IP разработками и сокращение стоимости услуг.
Эффективное решение для одновременных мультимедийных услуг, включающих в себя речь, данные и развитые услуги реального времени.
Более высокий уровень управления услугами.
Интегрированные и сокращенные по стоимости ЭиТО за счет IP.
Получение преимущества от приложений ИС, поддерживая терминалы, которые является IP клиентами.
Снижение стоимости посредством пакетной передачи на транспортном уровне.
4.1.1. Общие требования
1. Основной целью сети ОИП является поддержка услуг, подобных услугам ГСПС по Версии 99 и новым инновационным услугам. При назначении такие услуги должны обеспечивать межсетевой обмен совместно с существующими услугами ГСПС.
2. В дополнение, должно быть также возможным поддержание существующих (версий R00 и более ранних) услуг/возможностей (передачи речи, данных, мультимедиа, СКС (SMS), дополнительных услуг, ВДС,...) способом, прозрачным для пользователей таких услуг [1]. То есть для сети необходимо обеспечение возможностей услуг, требуемых в таком случае для поддержки межсетевого обмена этими услугами между сетью ОИП по версии R00 и другим семейством сетей с вариантом двухдоменной архитектуры (ГСПС по предварительной Версии 99, УМТС по Версии 99).
3. Стандарт должен делать возможным базовой сети ОИП поддерживать терминалы КК по Версии 99. Это должно быть стандартизовано таким образом, чтобы разрешить операторам принимать решение, желают ли они поддерживать терминалы КК только Версии 99.
4. Поддержка существующих услуг не будет препятствовать расширению возможностей услуг, которое возможно посредством использования ОИП архитектуры.
5. Когда развернут сети ОИП, то будут присутствовать услуги и базы данных, предназначенные для уже существующих сетей, не являющихся основанными на общем IP, например, переносимость (совместимость) локальных номеров, бесплатный вызов, специализированные корпоративные услуги. ОИП архитектура будет нуждаться в том, чтобы быть способной получать доступ к таким услугам.
6. Базовая сеть ОИП, соответствующая R00, будет допускать реализации, имеющие домены КК и КП, которые разделены, как и оба таких домена в архитектуре по версии R99. Такая реализация разрешает двум доменам быть развернутыми независимо, например, для объединения домена КП, использующего общий IP согласно версии R00, с основанном на РСП домене КК согласно версии R99. Более того, будет возможно реализовать домен КК, который использует ОИП архитектуру и в различных зонах обслуживания той же сети с доменом КК, основанном на РАП/РСП. Это допускает плавный переход ко всем базовым сетям ОИП.
ОИП архитектура по версии R00 будет поддерживать то, что все услуги разделят транспортный уровень канала-носителя, или канала передачи данных, и управление каналом-носителем.
Архитектура по версии R00 позволит оператору связи переходить от сети по версии R99 к сети по версии R00 без необходимости изменения технологии транспортной сети, схемы нумерации узлов и т.д.. Сети по версии R00 будут также допускать соединение УНСРД через интерфейс Iucs, чтобы предоставить оператору связи гибкость в реализации сети.
Отметим, что в общей архитектуре по версии R00 должны быть возможны другие транспортные технологии, кроме IP.
4.2. Возможности услуг
4.2.1. Общие положения
Идентифицированы следующие общие возможности услуг:
1. В сети ОИП по версии R00 должен быть возможен легальный перехват.
2. В сети ОИП по версии R00 должны быть поддержаны аварийные вызовы.
4.2.2. Основные требования для платформ услуг и приложений
Перечень требований к блоку «Приложение и Услуга»:
Возможности услуг должны быть сделаны доступными для Приложений посредством свойств возможностей услуг. Свойства возможностей услуг поставляют с помощью одной или более возможностей услуги (возможно, непосредственно обеспечиваемой сетевыми функциями, например ДСА, ФУСВ и т.д.), как показано на Фиг.4-1.
Фиг.4-1 Связи между свойствами возможностей услуг (СВУ) и возможностями услуг
3. Должно быть возможным поэтапное введение свойств возможностей услуг сетевым оператором связи для тех свойств возможностей услуг, которые конкретны для оператора связи.
4. Для доступа приложений к свойствам возможностей услуг должен быть введен стандартный интерфейс, называемый интерфейсом приложения, или прикладным интерфейсом.
5. Интерфейс приложения должен обеспечивать доступ к свойствам возможностей услуг на основании пользовательского профиля, или параметров настройки, для подписки.
6. Приложения могут быть расположены как на серверах, так и/или на (подвижных) терминалах.
7. Приложения могут осуществлять доступ к возможностям услуг доступа посредством свойств возможностей услуг.
8. Приложения могут использовать как возможности, поставляемые функциями сети подвижной связи, так и функции, поставляемые системами IT (нет расшифровки, по сокращениям возможно, «передачи информации») посредством свойств возможностей услуг.
4.3. Схемы нумерации
Стандарты должны позволять маршрутизировать передачу данных к подвижным абонентам на основе единственного идентификатора, например «MSISDN». Это не исключает использование множественных адресов для различных услуг и возможностей (например, передача данных, факсимильная связь, СКС). Сеть будет маршрутизировать вызов к терминалу через доступные ресурсы в зависимости от, например, возможности терминала, загрузки трафика и зоны обслуживания. Сети, переходящие к ОИП архитектуре, будут требовать возможности маршрутизации на основании единственного идентификатора для поддержания прозрачности услуг.
4.4. Терминалы по Версии 99
См. раздел 4.1.1 выше по тексту: следующие требования для поддержки терминалов по Версии 99 являются опцией, конкретной для оператора связи.
1. Стандарты должны разрешать базовой сети ОИП поддерживать терминалы УМТС по Версии 99.
2. Речевые услуги, включающие в себя аварийные вызовы, должны быть обеспечены в сетях ОИП для любого терминала УМТС по Версии 99, который поддерживает такие услуги.
3. Чтобы гарантировать роуминг для терминалов УМТС по Версии 99, которые не имеют возможности РДИП, речевые услуги, включающие в себя аварийные вызовы, должны быть доступны на основании возможностей КК таких терминалов.
4.5. Вопросы радиосвязи
1. Использование радиоресурсов должно быть оптимизировано в рамках архитектуры как для поддержки услуг, так и для поддержки сигнализации.
2. Разделение функциональности, относящейся к радиосвязи и не относящейся к радиосвязи, между базовой сетью и сетью радиодоступа.
3. Разделение стеков протоколов пользовательского уровня и уровня управления в сетях радиодоступа.
4. Процедуры быстрого доступа по восходящей линии связи и быстрого предоставления ресурса в обеих восходящей и нисходящей линиях связи для мультиплексирования трафика на одной линии радиоэфира (радиосвязи).
5. Оптимизация транспорта со сквозным IP для некоторого класса приложений реального времени (например, сжатие заголовков, расщепление заголовков).
6. Управляемая сетью процедура передачи обслуживания с короткими прерываниями для поддержки приложений реального времени (см. требования к передаче обслуживания, раздел 4.9).
7. Стеки протоколов в сети доступа для поддержки диапазона услуг с различными требованиями КО.
8. Межсетевой обмен/функциональная совместимость способов реализации КО, разработанных для сетей радиодоступа, и способов реализации КО, используемых в базовой сети с пакетной передачей.
9. Возможность дифференциации каналов-носителей (каналов передачи данных) в сети доступа для мультиплексирования различных типов трафика по радиоэфиру для достижения максимального использования спектра.
10. Оптимальное кодирование и перемежение для некоторых приложений таких, как передача речи.
11. Поддержка множественный потоков данных с различным КО для IP адресов (как определено в схеме КО по Версии 99).
12. Эффективность спектра должна быть максимизирована (например, статистическое мультиплексирование).
13. РРЗС должен поддерживать услуги УОНПР и РУОНПР для терминалов, соответствующих предварительной Версии 2000.
4.6. Межсетевой обмен
1. Базовая сеть ОИП должна поддерживать межсетевой обмен с внешними сетями, использующими IP, и не использующими IP (например, сети с коммутацией каналов (КТСОП, ЦСИУ, GSM СОПНПО (PLMN) УМТС СОПНПО,...). (PLMN - Сеть общего пользования наземных подвижных объектов, СОПНПО)
4.7. Управление мобильностью
1. Базовая сеть ОИП должна обеспечивать ориентированные на потоки и осуществляемые под управлением БС процедуры передачи обслуживания для УМТС.
4.8. Роуминг
1. Стандарт должен разрешать сети ОИП поддерживать роуминг с сетями ГСПС/УОНПР 2П и сетями УМТС по Версии 99.
4.9. Передача обслуживания
Поддержка передачи обслуживания между сетевыми технологиями по Версии 98, Версии 99 и Версии 2000 является существенной при поддерживании адекватной зоны обслуживания сети. Таблица 4-1 иллюстрирует необходимые сценарии передачи обслуживания и статус разработки способов и средств.
Передача обслуживания для сети ОИП УМТС
КК
(R99)
(Услуги КП)
R00*
R00
R00*
R00
(Услуги КК)
R00
R00
Ключ:
Отлично - одинаковая технология
Требуется R00 - Требуется для Версии 2000
*Причастность требований для передачи обслуживания КП к/от КК в Версии R00 являются предметом многочисленных дебатов. Другие варианты как для поддержки передачи обслуживания, так и для обеспечения зоны обслуживания услуг нуждаются в проведении исследования.
4.9.1. Категории передач обслуживания
1. Передача обслуживания внутри сети
Передача обслуживания внутри одной сети ОИП
1а. Передача обслуживания внутри РЗС (Региональная зональная сеть, СРД)
2b. Передача обслуживания между РЗС
2. Межсетевая передача обслуживания
Передача обслуживания между двумя сетями ОИП
3. Межсистемная передача обслуживания
Передача обслуживания между сетью ОИП и другими системами
4.9.2. Общее определение
Повторный выбор и передача обслуживания являются двумя способами поддержки мобильности в течение активного сеанса. Повторный выбор является процессом, в котором подвижная станция автономно определяет, какая ячейка-сота подвижной связи будет принимать услуги. Передача обслуживания является процессом, в котором сеть определяет, какая ячейка-сота подвижной связи будет принимать услуги.
4.9.3. Общие требования
Для услуг реального времени будет использована процедура передачи обслуживания. Сеть будет управлять процедурой передачи обслуживания.
Передача обслуживания должна быть выбираемым способом подвижной связи, если один или более активных сеансов запросили передачу обслуживания в многосеансовом вызове с различными требованиями к КО.
Требования производительности к прерыванию речи (т.е. интервал «приглушенного звука») должны быть эквивалентными или более высокими, чем для передачи обслуживания в ГСПС или ANSI-136 для услуг телефонии. TBD (нет расшифровки) для других услуг предложены сетью ОИП.
Поддержание максимального предела пакетных потерь (т.е. менее TBD) в течение передачи обслуживания.
Услуги, предоставляемые не в реальном времени, будут использовать либо передачу обслуживания, либо повторный выбор, зависящий от параметров КО в сочетании с параметрами сети.
Подписанный уровень КО следует поддерживать через границу передачи обслуживания. Однако согласование КО (если необходимо) следует сделать возможным до, в течение и после передачи обслуживания (Приложение может отвергнуть предложенное КО).
Процедура передачи обслуживания должна эффективно использовать радиоресурсы.
Передача обслуживания не должна подвергать угрозе безопасность: сети, поставляющей новые радиоресурсы; (возможно отличающуюся) сеть, поставляющую радиоресурсы источника; и терминальное ПО.
Должно быть эффективным использование множественных каналов-носителей, например, если одновременно идет передача речи и электронной почты.
Существенная информация заголовка IP/UDP/RTP (для внутрисетевой и межсетевой передачи обслуживания в сети ОИП, как это видимо конечным IP пунктом, должна быть сохранена через границу передачи обслуживания. Требуемая существенная информация заголовка зависит от канала-носителя.
4.9.4. Требования к ПС (PS)
Подвижная станция должна быть способной поддерживать и повторный выбор, и передачу обслуживания.
Подвижная станция должна помогать РЗС в принятии решений по передаче обслуживания, подавая информацию о РЧ среде (например, силу принятого сигнала от обслуживающей ячейки-соты и соседних ячеек-сот).
4.9.5. Требования к РЗС
Принятие решений по передаче обслуживания должно быть основано на РЗС.
Поддержание параметров КО РЗС, ассоциированных с подвижной станцией, через границу передачи обслуживания. Отметим, что параметры КО РЗС для подвижной станции основаны на согласованном множестве параметров КО.
Содействие контролю за соединением для оптимизации радиоресурсов.
Осуществление выбора цели передачи обслуживания на основании критерия такого, как информация о РЧ среде, радиоресурсы соседних ячеек-сот, требования к КО в пределах сеанса, и т.д.
4.10. Управление вызовом и роуминг
Следующие требования необходимо рассматривать для поддержки роуминга в сети ОИП.
1. Маршрутизация сигнализации и транспорта должна быть оптимизированной для целей управления вызовом и роуминга между сетями.
2. Когда только возможно, «отзвон» пользовательского сеанса по передаче речи или данных обратно к домашней среде не должен быть использован при представлении пользователю услуг при роуминге за границами домашней сети.
3. Сеть по Версии 2000 должна исполнять обязательные требования для аварийных услуг.
4. Сеть по Версии 2000 должна исполнять обязательные требования для переносимости номеров.
5. Сеть по Версии 2000 должна поддерживать сеансы коллективного пользования для передачи речи и данных, включающие в себя возможности для пользовательской логики или логики услуг динамически добавлять или удалять пользователей из активного сеанса передачи данных.
6. Сеть по Версии 2000 должна быть способной принимать и повторно маршрутизировать входящие запросы на передачу речи или данных, которые адресованы к пользовательским телефонным номерам в течение интервалов времени согласования национальных планов нумерации (например, расщепления ЗНП в Северной Америке).
7. Кодирование передачи трафика (речи, данных, видео) должно быть минимизировано. Например, если терминальное оборудование вызываемой и вызывающей сторон имеют одинаковый вокодер, то внутри сети не будет происходить кодирования трафика речи.
8. Сеть по Версии 2000 должна обеспечивать соединение с услугами действующих сетей 2П и версии 99.
9. Сеть по Версии 2000 должна обеспечивать ВДС для средств реализации роуминга.
10. Минимальный набор услуг для средств роуминга должен быть предусмотрен внутри обслуживающей сети. Такой минимальный набор пользовательских услуг находится в состоянии определения. Однако предвидят, что в минимальном наборе пользовательских услуг будет следующее:
a. Инициирование сеанса передачи речевого вызова и данных.
b. Завершение сеанса передачи речевого вызова и данных.
с. Ожидание вызова для речевых вызовов в случае сеанса, использующего однородную среду.
d. Услуги пересылки вызовов для речевых вызовов.
e. Информация (по) идентификации вызывающей стороны.
f. СКС
11. В том случае, когда оператор связи для сети ОИП по Версии 2000 не имеет действующей сети на «рынке услуг», на котором развертывается Версия 2000 сети ОИП, то оператор связи для Версии 2000 сети ОИП не имеет каких либо деловых связей с операторами действующих сетей. Следовательно, разработка Версии 2000 сети ОИП не может допустить, чтобы требования для предписанных услуг или услуги, конкретные для оператора связи, могут быть удовлетворены пересылкой вызова из сети ОИП по Версии 2000 к действующей сети. Нижеследующее является примерами услуг оператора связи, которые (вероятно) могут потребовать обработки непосредственно сетями Версии 2000 ОИП:
a. Оказание помощи по (сетевому) каталогу
b. Формирование счетов оплаты за услуги третьей стороны
с. Сбор вызовов
d. Вызовы по телефонным карточкам
Когда пользователь Версии 2000 ОИП переходит от сети ОИП по Версии 2000 к другой сети ОИП по Версии 2000 и получает доступ как к транспортным услугам (например, УОНПР), так и к услугам прикладного уровня (например, к вызовам мультимедиа), то услуги могут быть предоставлены посредством ФУСВ в обслуживающей сети или посредством ФУСВ в домашней сети. Обслуживающая сеть должна содержать информацию, чтобы обратиться к домашней сети пользователя для информации о пользовательском профиле, или параметрах пользовательской настройки. ФУСВ обслуживающей сети должна иметь доступ к необходимой информации для вызова и управления пользовательскими расширенными/вспомогательными услугами в пользовательской домашней сети.
13. Пользователь должен иметь возможность получать доступ к ПУИ или к услугам прикладного уровня корпоративной ЛВС.
14. Должны быть поддержаны как динамические, так и выделенные адресы IP.
15. Версия 2000 сетей ОИП будет способна обеспечить функциональность ВЧС. ВЧС ссылается как к ГСПС ВЧС, так и к Интранет. Поддерживаемые свойства ВЧС требуют дальнейшего изучения и анализа.
16. Когда ПО использует услугу сервера ФУСВ/ЦКПС, то серверу ФУСВ/ЦКПС необходимо аутентифицировать ПО. Способ, по которому это осуществляют, когда ПО использует услуги ФУСВ в визитной сети, требует дальнейшего изучения и анализа.
4.11. Безопасность
Общий принцип для безопасности при реализации сети ОИП заключается в том, чтобы по возможности повторно использовать те же способы и средства, которые разработаны для Версии 99 ПП3П.
5. Архитектура СОПНПО на основе ОИП
5.1. Эталонная архитектура
Эталонная архитектура обеспечивает два варианта:
Вариант 1: Был разработан с целью позволить операторам связи развертывать ОИП архитектуру, чтобы обеспечивать беспроводные/подвижные услуги 3 поколения. Эта архитектура основана на пакетных технологиях и IP телефонии для предоставления одновременно услуг в реальном времени и услуг не в реальном времени.
Вариант 2: Одной целью варианта 2 является также допустить поддержку терминалов доменов КК по версии 99. В дополнение, вариант 2 поддерживает также основанные на IP услуги по варианту 1.
5.1.1. Эталонная архитектура - Вариант 1
Как описано ранее в разделе 4.1 «Общие положения», архитектура показанная на Фиг. 5-1, была разработана с целью позволить операторам связи развертывать основанную на IP архитектуру с целью доставки услуг беспроводной/подвижной связи 3го поколения. Такая архитектура основана на пакетных технологиях и IP телефонии для предоставления услуг одновременно в реальном времени и не в реальном времени.
Показанная архитектура и ее компоненты, которые описаны в последующих разделах, допускают гибкие и расширяемые способы и средства для поддержания глобального роуминга и способности к взаимодействию с внешними сетями такими, как например, СОПНПО, действующие сети 2П, СПДОП (PDN, Сеть передачи данных общего пользования, СПДОП) и другие сети РДИП мультимедиа.
Сквозная архитектура состоит из следующих ключевых сегментов:
a) Радиосеть
b) Сеть УОНПР
c) Управление вызовом
d) Шлюзы ко внешним сетям
e) Архитектура услуг
Часть, относящаяся к радиосети, состоит из оборудования, связываемого с подвижным пользователем, Линией связи радиоэфира и Сетью радиодоступа. СРД поддерживает как УНСРД, так и технологии РДГС.
В разделе 4 указано, что назначением части, относящейся к базовой сети ОИП архитектуры заключается в том, что она должна быть разработана так, чтобы позволить операторам связи использовать другие сети доступа, например РРЗС и HIPERLAN 2. На Фиг. 5-1, РРЗС показан явно, тогда как другие сети доступа изображены в виде овала, помеченного как «Сеть с другим доступом».
Для целей настоящего отчета РРЗС определен как расширенное ОБС ГСПС, поддерживающее схемы модуляции РДГС на основе 200 кГц и пакетные услуги реального времени.
Поддержка сетей с другим доступом и влияние ОИП архитектуры на РРЗС выходят за объемы настоящего отчета (деятельности). Тем не менее, для того чтобы избежать потери информации, в отчете указано, какие требования известны для применения к таким сетям доступа.
В пределах настоящего отчета, опорная точка между РРЗС и базовой сетью обозначена как Iu_ps. То есть опорной точкой является Iu и ожидают, что реализация будет сходной с Iu_ps.
Отметим: использование метки Iu_ps, как обозначение опорной точки, вносит сложности. В течение деятельности по стандартизации следует выбрать более подходящую метку.
Часть сети УОНПР имеет УПУ, которые обеспечивают управление мобильностью и услуги активизации контекста PDP для подвижного терминала, как они делают для домена КП сети УОНПР по версии R00. Функциональность ОРМ (Опорный регистр местоположения, HLR) для сети УОНПР поддержана Домашним сервером абонента (ДСА).
Часть архитектуры для Управления вызовом является наиболее критичной функциональностью. ФУСВ, ФУМШ, ШС-Р, МШ, ШС-Т и ФМР содержат функциональность Управления вызовом и сигнализации для доставки подвижных/беспроводных услуг реального времени. ФУСВ сходна с контроллером зоны согласно H.323 или Сервером SIP. Архитектура преднамеренно была сохранена общей и не основана на конкретных средствах управления вызовом таких, как H.323 или SIP. Такой выбор - для дальнейшего изучения.
Пользовательские профили поддерживают в ДСА. Сигнализация в сети IP-мультимедиа является интерфейсом исключительно через ФУСВ в то время, когда канал-носитель связан непосредственно с УПМУ. ФМР сопрягают со всеми компонентами канала-носителя для среды (носителя) канала и с ФУСВ для сигнализации. ФМР обеспечивает смешение сред, мультиплексирование, другие функции обработки и создания.
Межсетевое взаимодействие с внешними сетями такими, как СОПНПО, другие СПДОП, другие сети РДИП мультимедиа и действующие сети 2П (ГСПС или МДВР (TDMA)), поддерживают посредством функциональных элементов УПМУ, ФУМШ, МШ, ШС-Р и ШС-Т. Другие СОПНПО сопряжены как для В-канала, так и сигнализации через соответствующие им компоненты УОНПР. ФУСВ является новым компонентом, который также участвует в такой сигнализации.
Сигнализацию к подвижным действующим сетям сопрягают через ШС-Р, ФУСВ, ФУМШ, ШС-Т и ДСА, тогда как В-канал сопряжен с и от действующей сети КТСОН через МШ.
Сигнализация действующей наземной линия связи с коммутацией каналов сопряжена через ФУСВ, ФУМШ и ШС-Т, тогда как В-канал сопряжен с действующей сетью КТСОН и от действующей сети КТСОН через МШ.
Часть Архитектуры услуг сети на данной фигуре изображена как внешний элемент и подробно описана в разделе 10. Нестандартные услуги поставляют через интерфейсы к услугам прикладного уровня. ДСА, УУОН И ФУСВ сопряжены с приложением и услугами и показаны овалами.
Подробности для каждого из функциональных элементов архитектуры приведены в последующих подразделах настоящего документа.
Фиг.5-1: Эталонная архитектура для варианта 1
Интерфейс Gm между ПО и ФУСВ состоит из мультимедиа-сигнализации от пользователя к сети. Сигнализацию передают по радио, lu, Gn и Gi интерфейсам.
УУОН и УПМУ являются такими же функциональными элементами, как определено в 23.002 [4] для УМТС по версии 99.
Процедуры управления мобильностью для подвижных станций (ПС), соответствующих сети ОИП по Версии 2000, в сети ОИП по Версии 2000 основаны на Идентификаторе зоны маршрутизации (ИдЗМ). Процедуры управления мобильностью для ПС, допускающих КК, в сетях ОИП по Версии 2000 основаны на Идентификаторе зоны маршрутизации (ИдЗМ) и на Идентификаторах зоны местоположения. В случае роуминга между сетями ОИП по Версии 2000 и сетями 2П и обратно, необходим способ для преобразования формата идентификаторов (т.е. ПС, осуществляющей роуминг от сети ОИП по Версии 2000 к сети 2П, известна только старая Зона местоположения (ЗМ), но ЦКПС 2П должен быть также предоставлен Идентификатор зоны местоположения). При роуминге от сети ЗП по версии R00 к 2П (без возможности объединенного обновления) открытым вопросом остается то, как ЦКПС-2П может извлекать IMSI от базовой сети ОИП.
Идентичность ПС (Международный идентификационный номер подвижного абонента, МИНПА, IMSI) защищена через радиоинтерфейс принятием единственного временного идентификатора (Временный идентификатор подвижного абонента, ВИПА, TMSI), который распределяет УУОН в течение процедуры регистрации ПС. ВИПА может быть перераспределен при каждой следующей регистрации или обновлении зоны маршрутизации [в соответствии со сценарием роуминга между сетями ОИП по Версии 2000 и действующими сетями сотовой связи].
Узлы Сети Доступа (УПУ, РСК) не осведомлены о протоколе мультимедиа-сигнализации между ПО и ФУСВ. Они даже не осведомлены о том, что данный ПО посылает или не посылает сигнализацию к ФУСВ.
Примечание 1: Это не препятствует тому, что для оптимизации радиоресурса, РСК может поддерживать конкретный (специальный) RAB (нет расшифровки) в для индивидуальных потоков мультимедиа на пользовательском уровне. Этот RAB запрашивает ПО при активизации контекста PDP.
Примечание 2: УУОН может играть роль при осуществляемом ПО выборе ФУСВ. Это является ДДИ. Но даже если УУОН участвует в определении адреса ФУСВ, УУОН не выполняет регистрацию мультимедиа от имени ПО.
Другие контексты PDF переносят мультимедиа-сигнализацию и пользовательские потоки в соответствии с различными требованиями к КО для этих контекстов PDF. Узлы Сети Доступа (УПУ, РСК) тем не менее не осведомлены, переносит ли мультимедиа-сигнализацию данный контекст PDF или нет.
Принципы работы архитектуры
1. Базовая сеть ОИП первоначально была создана, чтобы использовать общую технологию (IP) для поддержки всех услуг, включая в их состав мультимедийные и речевые услуги, управляемые согласно H.323/SIP или ППСЦ (ППИУ).
2. Сетевая архитектура основана на пакетных IP технологиях, предназначенных для предоставления одновременно услуг в реальном времени и услуг не в реальном времени.
3. Сетевая архитектура основана на эволюции УОНПР.
4. Для поддержки услуг домена КК, соответствующих версии R99, могут быть повторно использованы средства БС для домена КК, соответствующие версии R99. (Отметим: Это не препятствует использованию операторами связи для доставки услуг домена КК по версии R99 альтернативных средств таких, как H.323, SIP или развернутых форм средств УВ домена КК по версии R00.
5. Для поддержки версии 00 терминалы являются основанными на IP, и интеграцию услуг получают посредством IP.
6. Сетевая архитектура должна поддерживать персональную мобильность и способность к взаимодействию между подвижными и фиксированными сетями связи как для речевых услуг, так и для услуг данных.
7. Поддержать или повысить качество уровней услуг по сравнению с сетями, используемыми в настоящее время.
8. Поддержать или повысить надежность сети по сравнению с сетями настоящего времени.
9. Интерфейсы ОИП и соответствующие сетевые интерфейсы должны быть расширены для поддержания мультимедийных услуг реального времени.
10. Сетевая архитектура обеспечит разделение управления услугами и управления вызовом/соединением.
11. Сетевая архитектура осуществит замену транспорта (транспортного протокола) согласно SS7 на IP.
12. Сетевая архитектура будет независимой от сетевых транспортных уровней для уровня 1 (У1, LI) и уровня 2 (У2, L2).
13. Независимо от типа услуги, на основании ППИУ или на основании IP, транспорт IP должен быть возможен для общего транспорта сигнализации и данных.
5.1.2. Эталонная Архитектура - Вариант 2
Как описано ранее в разделе Общих Требований 4.1.1 в пунктах 3 и 6, архитектура, показанная на Фиг.5-2, дает возможность операторам связи переходить от сети УМТС по версии R'99 к сети ОИП версии R'00. Одной из целей варианта 2 является допустить поддержку терминалов КК по версии 99. Вариант 2 допускает независимое развертывание двух доменов по версии R'99.
Как и для варианта 1, архитектура по варианту 2 допускает, что все услуги, поддерживаемые вариантом 2, разделяют транспортный уровень канала-носителя и управление каналом-носителем. Должны быть допущены различные базовые транспортные средства (например, RTP/UDP/IP, AAL2/РАП или РСП).
Эталонная архитектура по варианту 2 включает в себя услуги на основании УУОН/УПМУ/ФУСВ согласно эталонной архитектуре по варианту 1. Следовательно, определения и принцип работы архитектуры, описанные в главе 5.1.1, также применимы в части УУОН/УПМУ/ФУСВ варианта 2.
[Отметим: требование в разделе 4.3 поддержки маршрутизации по единственному ПС ЦСИУ или разрешение операторам связи на перемещение абонентов от услуг КК к услуге ОИП без изменения ПС ЦСИУ будет решено как часть версии R00.] В вариант 2 добавлены два элемента управления, относящихся к архитектуре домена КК по версии R'99, сервер ЦКПС и сервер ШЦКПС.
Вариант 2 извлекает преимущество из архитектуры (интерфейса) Iu по версии R'99 в том, что имеет транспорт пользовательских данных, отделенный от управления, чтобы позволить УНСРД осуществлять доступ к базовой сети через МШ, выделенный из сервера ЦКПС. Между УНСРД и ЦКПС используют подсистему управления (интерфейсом) Iu, RANAP (нет расшифровки).
[Отметим: 1) Должны быть сделаны строгие определения РРЗС относительно ГСПС/услуги дистанционной передачи речи и относительно сервер ЦКПС/МШ. 2) Возможность сопряжения ГСПС/ОБС с сервером ЦКПС следует изучать дополнительно.].
Допуская для серверов завершение МАР и сигнализации пользовательской сети (04.08+УВ+УМ), могут быть выполнены требования, относящиеся к переходу услуг и сетей, для услуг домена КК УМТС по версии R'99 и сети. Требованиями, которые необходимы для архитектуры сети в соответствии с вариантом 2, являются:
Фиг.5-2: Эталонная архитектура для варианта 2
Iu - опорная точка между УНСРД и базовой сетью. Между УНСРД и УУОН используют Iu на основании IP. Между УНСРД и МШ могут быть использованы точки Iu (RTP, AAL2) на основании других транспортных технологий.
МАР действует между ДСА и сервером ЦКПС и сервером ШЦКПС соответственно.
5.1.3 Что является границей сети
Открытый вопрос: Что является границей сети
В случае, когда УПМУ рассматривают как границу сети в направлении к сети IP или УПМУ+МШ рассматривают как границу сети в направлении КТСОН/действующая сеть, то необходимо пояснить следующие вопросы: как определять МШ и как гарантировать оптимальную маршрутизацию к этому МШ. При настройке вызова ФУСВ необходимо определить соответствующий МШ для вызова. Например, необходимо определить, является ли данный вызов вызовом к КТСОН (и в таком случае к какой сети КТСОН) или к сети «Речевые данные по IP». Такое определение может быть гарантировано только тогда, когда сигнализация настройки вызова была проанализирована ФУСВ и, возможно, ФУУ. Такой анализ может изменить номер вызываемой стороны (например, изменить адрес вызываемой стороны от адреса, соответствующего терминалу IP, на адрес, соответствующий терминалу внешнего КТСОН). Только в этой точке может быть определен наилучший МШ. Такое определение не может быть сделано ранее посредством УУОН. Адрес МШ посылают обратно (через сигнализацию H.225) к ПО. Затем ПО может активизировать контекст PDP (для поддержки трафика пользовательского уровня) к соответствующей сети (т.е. к сети, позволяющей наилучшим образом достичь МШ, который должен быть использован вызовом).
Отметим [ДДИ]. Вопрос оптимальной маршрутизации при добавлении ФМР не может быть определен до соглашения о том, что является границей сети.
5.2. Новые функциональные элементы
5.2.1. Функция Управления Состоянием Вызова (ФУСВ)
В последующем разделе функции ФУСВ были разбиты на несколько логических компонентов.
На текущий момент, такие логические компоненты являются внутренними для ФУСВ. Потребность для внешних компонентов в возможности адресовать непосредственно один из логических компонентов ФУСВ - для ДДИ.
Каждая ФУСВ, действующая в качестве ФУСВ обслуживания (см. раздел 9), имеет функцию ФУВ.
ШВВ (Шлюз входящего вызова)
Действует в качестве первой точки входа и выполняет маршрутизацию входящих вызовов.
Переключение, или срабатывание, услуг входящего вызова (например, безусловный вызов экранирования/вызов пересылки) может потребовать быть резидентным для целей оптимизации.
Обработка запроса адреса (подразумевает административную зависимость с другими элементами).
Обмен информацией с ДСА.
ФУВ (Функция управления вызовом)
Управляет настройкой/завершением и состоянием/событием вызова.
Взаимодействует с ФМР для того, чтобы поддержать коллективный вызов и другие услуги.
Сообщает о событиях вызова для формирования счетов оплаты услуг, аудита, перехвата или для другой цели.
Принимает и обрабатывает регистрацию на прикладном уровне.
Обработка адреса запроса (подразумевает административную зависимость).
Может предоставлять средства переключения услуг (свойства возможностей услуги) к сети Приложения и услуг (ВДС/АОУ).
Может запускать услуги, зависящие от местоположения и соответствующие обслуживающей сети.
Может проверять, разрешена ли запрошенная исходящая связь, заданная текущей подпиской (для текущей подписки).
БДПО (База данных профиля обслуживания, SPD)
Взаимодействует с ДСА в домашнем домене для приема информации о пользовательском профиле пользователя сети ОИП, соответствующей версии R00, и может сохранять ее в зависимости от СУУ (вместе) с домашним доменом.
Уведомляет домашний домен начального пользовательского доступа (включает в себя, например, адрес ФУСВ для транспорта сигнализации, идентификатор пользователя и т.п., требует дальнейшего анализа).
Может кэшировать информацию, относящуюся к доступу (например, IP адрес(ы) терминала, по которому можно найти пользователя и т.п.).
ОА (Обработка адреса)
Анализ, преобразование, модификация при необходимости, переносимость адреса, соответствие адресам псевдонимов.
Может выполнять обработку временных адресов для межсетевой маршрутизации.
Другие функции такие, как контроль за соединением, знание о множественных сеансах в пределах одной ФУСВ, множественные ФУСВ, обслуживающие один терминал для многих услуг, роли множественных ФУСВ, обслуживающих сеть и т.п., требуют дальнейшего исследования.
Интерфейсы должны быть дополнительно изучены и определены.
5.2.2. Домашний сервер абонента (ДСА)
Домашний сервер абонента (ДСА) является основной базой данных для данного пользователя. Он ответственен за сохранение основного перечня свойств и услуг (либо непосредственно, либо через серверы), ассоциированных с пользователем, и за слежение за положением и за средствами доступа для своих пользователей. ДСА поставляет информацию о пользовательском профиле, либо непосредственно, либо через серверы. ДСА являет собой расширенный вариант функциональности Опорного регистра местоположения (ОРМ), например как определено в ГСПС МАР, но отличается тем, что ему необходимо взаимодействовать также через новые, основанные на IP интерфейсы. ДСА должен поддерживать профиль подписки, который идентифицирует для конкретного пользователя, например:
Идентификации пользователя
подписанные услуги и профили
информацию, конкретную для услуги
информацию по управлению мобильностью
информацию по авторизации.
Подобно ОРМ, ДСА содержит или имеет доступ к центрам/серверам аутентификации (например, AUC, AAA).
Фиг.5-3: Пример общей структуры ОСА и основные интерфейсы
Фиг.5-4: Пример структуры ОСА с конкретной функциональностью СПМ
ДСА может состоять из следующих элементов, как показано на Фиг.3:
1) Сервер пользовательской мобильности (СПМ): он хранит профиль услуг сети ОИП по Версии 2000 (см. раздел 9.1) и хранит для пользователей информацию, относящуюся к мобильности услуг или к ФУСВ обслуживания. СПМ может также генерировать, хранить и/или управлять данными, предназначенными для защиты и политик безопасности (например, свойства, определенные Комитетом инженерной поддержки сети Интернет, КИПСИ, IETF). СПМ должен обеспечивать логическое имя для преобразования транспортного адреса, чтобы поставлять ответ на запросы ССИ. Роль СПМ и функциональная декомпозиция являются предметом дальнейшего анализа.
2) ОРМ 3П: ОРМ для УОНПР расширен для поддержания конкретной информации по УОНПР сетей ОИП по Версии 2000.
Gr и Gc используют МАР, которая может быть реализована с использованием МАР, транспортируемой через IP, однако должен быть рассмотрен вопрос роуминга в сети, которая поддерживает МАР через SS7. Интерфейс Cx требует дальнейшего анализа: он может быть реализован через протоколы КИПСИ, как, например, ССИ, или через процедуры МАР.
Следующая функциональность может потребовать поддержки в ДСА и предназначена для дальнейшего изучения:
Хранение профиля услуг сети ОИП по версии R00 и хранение для пользователей информации о местоположении.
Возможно, генерирование, хранение и/или управление данными, предназначенными для защиты и политик безопасности (например, свойства, определенные КИПСИ).
Возможно, потребуется обеспечение логического имени для преобразования транспортного адреса.
ДСА взаимодействует с ШС-Р, чтобы осуществлять связь с ВРМ и другими средствами управления мобильностью, которые не используют IP. ДСА сопряжен с ФУСВ через Cx, который является предметом дальнейшего изучения.
Другие функции сети ОИП по версии R00, как, например, AAA, ССИ и т.п., и их взаимодействия с ДСА являются предметом дальнейшего изучения.
Интерфейс(ы) между СПМ и 3П ОРМ - для дальнейшего изучения.
Отметим: Если пользовательский профиль расщеплен по различным базам данных, то данные следует поддерживать так, чтобы не было дублирования элементов информации и данные должны быть согласованными.
5.2.3. Функция транспорта межсетевой сигнализации (Т-МСС, T-SWG)
Этот компонент в сети ОИП по версии R00 является точкой завершения КТСОН/СОПНПО для определенной сети. Функциональность, определенная в пределах ШС-Т, должна быть согласованной с существующими/текущими промышленными протоколами/интерфейсами, которые удовлетворят настоящим требованиям.
Отображает относящуюся к вызову сигнализацию от/к КТСОН/СОПНПО на IP канал-носитель и посылает ее к/от ФУМШ.
Требует обеспечения отображения адресов транспортного уровня для КТСОН/СОПНПО <-> IP.
Интерфейсы требуют дальнейшего изучения и определения.
5.2.4. Функция роуминга межсетевой сигнализации (Р-МСС, ШС-Р)
Роль Р-МСС, описанная ниже, относится только к роумингу к/из (домена) КК 2П/R00 и домена УОНПР, к/из (домена) КК R00 и домена УОНПР и не затрагивает домен мультимедиа/РДИП.
Для того чтобы гарантировать надлежащий роуминг, Р-МСС выполняет преобразование сигнализации на транспортном уровне (преобразование: Sigtran SCTP/IP в SS7 MTP) между действующим, основанном на протоколе SS7 транспорте сигнализации и основанном на IP транспорте сигнализации. Р-МСС не интерпретирует сообщения МАР/САР, но, возможно, должна интерпретировать базовый уровень (протокола) SCCP, чтобы гарантировать надлежащую маршрутизацию сигнализации.
(Для поддержки терминалов КК 2П/R00): Услуги Р-МСС используют, чтобы гарантировать обеспечение транспортного межсетевого обмена между транспортом SS7 и IP для интерфейсов сигнализации МАР_E и МАР_G с ЦКПС/ВРМ по версии 2П/R99. Для домена мультимедиа/РДИП, обеспечение межсетевого обмена МАР и Р-МСС требует дальнейшего изучения.
5.2.5. Составной шлюз
Составной шлюз: логический объект, составленный из одиночного ФУМШ и одного или более MG, которые могут быть размещены на различных машинах. Вместе они сохраняют поведение шлюза таким, как определено в H.323 и H.246 (возможно включение серверов SIP и серверов ЦКПС в состав версии 2000).
5.2.6. Функция управления медиа-шлюзом (ФУМШ)
Этот компонент сети ОИП по версии R00 является точкой завершения КТСОП/СОПНПО для определенной сети. Функциональность, определенная в пределах ШС-Т, должна быть согласованной с существующими/текущими промышленными протоколами/интерфейсами, которые удовлетворят настоящим требованиям.
Управляет частями состояния вызова, которые соответствуют управлению соединением для каналов носителя в МШ.
Взаимодействует с ФУСВ.
ФУМШ выбирает ФУСВ в зависимости от номера маршрутизации для входящих вызовов от действующих сетей.
Выполняют преобразование протокола между действующей сетью (например, ППИУ, R1/R2 и т.д.) и протоколами управления вызовом для сети ОИП по версии R00 (этот вопрос еще находится в стадии дальнейшего изучения в промышленности).
Предполагают, что внешняя информация должна быть принята в ФУМШ и может быть переслана к ФУСВ/ШС.
Интерфейсы должны быть в дальнейшем изучены и определены.
5.2.7. Функция медиа-шлюза (ФМШ)
Этот компонент в сети ОИП по версии R00 является точкой завершения транспорта КТСОП/СОПНПО для определенной сети. Для архитектуры по варианту 2 компонент также используют для сопряжения УНСРД с базовой сетью ОИП через (интерфейс) Iu.
Функциональность, определенная в пределах МШ, должна быть согласованной с существующими/текущими промышленными протоколами/интерфейсами, которые удовлетворят настоящим требованиям.
МШ может завершать каналы-носители от сети с коммутируемыми каналами (например, DSO) и потоки данных от пакетной сети (например, потоки RTP в IP-сети). Через Iu МШ может поддерживать преобразование данных, управление каналом-носителем и обработку полезной информации (пакета) (например, кодека, эхокомпенсатора, моста конференций) для поддержки других опций Iu для услуг КК: основанных на AAL2/АТМ, а также основанных на RTP/UDP/IP. [Примечание: в общей архитектуре сети версии R'00 должны быть возможны другие транспортные технологии базовой сети, например РАП, РСП или IP.]
Взаимодействует с ФУМШ, сервером ЦКПС и сервером ШЦКПС для управления ресурсами.
Владеет и обрабатывает ресурсы такие, как эхокомпенсаторы и т.п.
Может потребовать наличия кодеков.
Влияния управления по каналам сети на МШ и сеть ОИП по версии R00 требуют дальнейшего изучения.
Функциональность доставки тонального сигнала вызова к КТСОП/СОПНПО требуют дальнейшего изучения.
МШ будет оснащен необходимыми ресурсами для поддержки УМТС/ГСПС транспортных носителей. Для H.248 может потребоваться дополнительная настройка (т.е. пакеты), чтобы поддержать дополнительные кодеки и протоколы синхронизации (формирования) кадров, и т.п.
Для архитектуры по варианту 2 управление каналом-носителем и обработка полезной информации (пакета) посредством МШ также потребуют поддержки конкретных для подвижной связи функций таких, как перемещение/передача обслуживания и привязка к опорной точке SRNS (SRNC - ОРСК) (отметим, что эти функции поддержаны посредством УУОН/УПМУ в архитектуре варианта 1 и не требуются в МШ). Ожидают, что для этого могут быть применены средства текущего стандарта H.248. Решения о том, как использовать общие средства H.248 для управления каналом-носителем, требуют дальнейшего изучения.
Интерфейсы требуют дальнейшего изучения и определения.
5.2.8. Функция мультимедиа-ресурса (ФМР)
Этот компонент выполняет функции коллективного вызова и проведения конференций с помощью мультимедиа. ФМР будет иметь такие же функции БМК (Блок многоточечной конференц-связи, БМК, БУС) в сети (согласно) H.323.
Отвечает за управление каналом-носителем (с УПМУ 3П и МШ) в случае коллективной/мультимедиа конференции.
Может взаимодействовать с ФУСВ для проверки правильности услуг для коллективных/мультимедиа сеансов. Обработка ресурсов таких, как двухстадийный набор номера, оповещение и т.п. требуют дальнейшего изучения.
Интерфейсы требуют дальнейшего изучения и определения.
5.2.9. Сервер ЦКПС
Сервер ЦКПС главным образом содержит управление вызовом и подсистемы управления мобильностью (для) ЦКПС ГСПС/УМТС по версии R00.
Сервер ЦКПС отвечает за управление такими вызовами для доменов КК, которые отправляют с подвижного терминала и завершают на подвижном терминале (04.08 УВ). Сервер завершает сигнализацию (04.08+УВ+УМ) пользовательской сети и преобразует ее в соответствующую сигнализацию сеть-сеть. Сервер ЦКПС также содержит ВРМ, чтобы сохранять данные услуг для подвижного абонента и данные, относящиеся к СПРЛПС.
ЦКПС сервер управляет частями состояния вызова, которые соответствуют управлению соединением для каналов носителя в МШ.
5.2.10. Межсетевой сервер ЦКПС (МЦКПС)
Сервер МЦКПС главным образом содержит управление вызовом и подсистемы управления мобильностью (для) МЦКПС ГСПС/УМТС по версии R00.
5.3. Описание опорных точек
5.3.1. Опорная Точка Cx (ДСА - ФУСВ)
Эта опорная точка поддерживает передачу данных между ДСА и ФУСВ.
Когда ПО зарегистрирован ФУСВ, то ФУСВ может обновить его положение по отношению к ДСА. Это позволит ДСА определять, к какой ФУСВ направлять входящие вызовы. При таком обновлении относительно ДСА, ДСА посылает данные абонента (относящиеся к приложению) к ФУСВ.
Для вызова ПТ ФУСВ запрашивает ДСА об информации маршрутизации вызова.
5.3.2. Опорная Точка Gm (ФУСВ - ПО)
Этот интерфейс должен позволять ПО взаимодействовать с ФУСВ, например:
Регистрация посредством ФУСВ,
Инициация и завершение вызова,
Управление вспомогательными услугами.
5.3.3. Опорная точка Мс (ФУМШ - МШ)
Опорной точкой Мс показаны интерфейсы между ФУМШ и МШ, между сервером ЦКПС и МШ, и между сервером МЦКПС и МШ. Она имеет следующие свойства:
Полная согласованность со стандартом H.248, основную работу по которому в настоящее время выполняют в Исследовательской группе 16 МСЭ (ITU) совместно с рабочей группой КИПСИ MEGACO.
Гибкая обработка соединений, которая допускает поддержку различных моделей вызовов и различные назначения обработки носителя, не ограниченные использованием согласно H.323.
Открытая архитектура, в которой могут быть выполнены работы по определению расширений/пакетов для интерфейса.
Динамическое разделение ресурсов узлов физических МШ. Физическая МШ может быть разбита на логически раздельные виртуальные МШ/домены, состоящие из множества статически распределенных оконечных нагрузок.
Динамическое разделение между доменами ресурсов передачи, поскольку МШ управляет каналами-носителями и управляет ресурсами в соответствии с протоколом H.248.
Для архитектуры по варианту 2 функциональность через опорную точку Mc будет требовать поддержки конкретных для подвижной связи функций таких, как перемещение/передача обслуживания и привязка к опорной точке ОРСК. Ожидают, что могут быть применены текущие стандартные средства H.248/IETF Megaco, чтобы это допустить. Решения о том, как использовать общие средства управления каналом-носителем согласно H.248 для конкретных для подвижной связи функций, требуют дальнейшего изучения.
5.3.4. Опорная точка Mh ( ДСА - Р-МСС)
Этот интерфейс поддерживает обмен информацией управления мобильностью и данными подписки между ДСА и R00/ действующими сетями подвижной связи. Он требует поддержки пользователей ОИП, которые осуществляют роуминг в сети 2П.
5.3.5. Опорная точка Мм (ФУСВ - сети IP мультимедиа)
Это - интерфейс IP между ФУСВ и сетями IP. Этот интерфейс используют, например, чтобы принять запрос вызова от другого сервера управления вызовом РДИП или терминала.
5.3.6. Опорная точка Mr (ФУСВ - ФМР)
Позволяет ФУСВ управлять ресурсами в пределах ФМР.
5.3.7. Опорная Точка Ms (ФУСВ - Р-МСС)
Этот интерфейс позволяет ФУСВ устанавливать связь с элементами действующей сети, например ДСА 2П, для управления положением (обновление положения и загрузка абонентских данных) и управления вызовами (например, ДСА 2П осуществляет поиск номера маршрутизации (НМ) для роуминга пользователя в соответствии с 2П).
5.3.8. Опорная Точка Mw (ФУСВ - ФУСВ)
Интерфейс допускает одной ФУСВ (например, опорной ФУСВ) передавать запросы вызова к другой ФУСВ (например, ФУСВ обслуживания).
5.3.9. Опорные точки Nc (Сервер ЦКПС - Сервер МЦКПС)
Через опорную точку Nc выполняют управление вызовом на основе сеть - сеть. Примерами этого являются ППИУ (или развертывание ППИУ для Управления вызовом независимого канала-носителя (УВНК). В базовой сети ОИП в опорной точке Nc используют основанный на IP транспорт сигнализации. [Отметим: В общей архитектуре версии R'00 для Nc будут возможны различные опции транспорта сигнализации.]
5.3.10. Опорные точки Nb (МШ-МШ)
Через опорную точку Nb осуществляют управление и транспорт. Транспортным (протоколом) может быть RTP/UDP/IP или AAL2 для транспорта пользовательских данных. Управление каналом-носителем через Nb является ДДИ, оно может быть основано на RTP, H.245 или соответствующих. [Отметим: в общей архитектуре по версии R'00 для Nb будут возможны различные опции для транспорта пользовательских данных и управления каналом-носителем, например: AAL2/Q.AAL2, STM/нет, RTP/H.245.]
5.3.11. От УУОН к приложениям и услугам
Интерфейс от УУОН к ПУО в домене Приложений и услуг является интерфейсом, определенным для УОНПР, чтобы поддерживать межсетевой обмен для подсистемы учета затрат.
5.4. Использование МАР/САР - Стек Протокола ниже МАР/САР - Общие рассмотрения
Ниже МАР и САР находится стек протоколов в пределах БС ОИП, как показано на Фиг.5-5:
SCCP И TCAP используют ниже САР и МАР. В действительности САР и МАР оба опираются на услуги, предусматриваемые этими базовыми протоколами (например, возможности транзакций, трансляции глобальных имен). Альтернативы для обеспечения услуг SCCP требуют дальнейшего изучения.
Нижние уровни передачи согласованы с набором протоколов IETF Sigtran, используемым для передачи сигнализации телекоммуникации на верхний уровень базового IP.
Фиг.5-5: Стек протоколов ОИП версии R00 для МАР/САР
Этот стек протоколов используют, чтобы передавать потоки МАР/САР:
- Внутри БС ОИП между узлами, завершающими МАР/САР: например, между ДСА или ПУО и функциями БС ОИП (УУОН, серверы ЦКПС...), обрабатывающими вызов/сеанс и требующими диалога с ДСА или ПУО для управления пользовательской мобильностью/поиска абонентских данных. Например, этот вариант соответствует интерфейсам Gr, Gc. Можно также предусмотреть (для этого необходимо дополнительное изучение) использование МАР на Cx для управления пользовательской мобильностью/поиском абонентских данных.
- В случае межсетевого обмена с узлами, не поддерживающими МАР/САР над стеком IP (например, 2П или с узлами сетей УМТС R00), но требующими диалога МАР/САР с узлом, поддерживающим такой МАР/САР над стеком IP. Такой стек протоколов используют между узлами, завершающими МАР/САР и ШС-Р. Интерфейс Mh должен использовать МАР над IP для сценариев роуминга, вовлекающего домен КК по версии R00 и УОНПР (при этом исключая домен РДИП/Мультимедиа), следовательно, это не исключает другие используемые протоколы. Использование МАР на Ms является ДДИ.
6. КО (Качество обслуживания)
Работа, которую в настоящее время осуществляют в рамках специального КО S2, отражена в TR 23.907 и в разделе КО в TR 22.105. Версия R99 этих описаний будет поддерживать приложения реального времени в сети с коммутацией пакетов, которая включает в себя способность УМТС к прозрачному поддержанию мультимдиа-приложений, использующих протокол H.323. Архитектура ОИП, как описано в настоящем документе, определяет реализацию функции управления вызовом, которая может быть основана либо на SIP, либо на H.323 в пределах СОПНПО. Следовательно, работа по КО R00 будет включать в себя любые изменения, требуемые для поддержки возможностей КО, которые необходимы, чтобы поддержать КО мультимедиа на основании H.323 или SIP в пределах СОПНПО. Осуществляя это, не ожидают введения каких-либо новых требований КО к уровню канала-носителя УМТС.
В дополнение, следует отметить, что существует также пожелание иметь мультимедиа-приложения с поддержкой ОИП архитектуры, которые используют протокол SIP. Однако работа по КО, относящаяся к протоколу SIP, будет предпринята в пределах ПП3П только тогда, когда ПП3П предпримет работу по поддержке протокола SIP. Тем не менее, предполагают, что работа по КО, сконцентрированная на H.323, непосредственно применима к SIP.
В дополнение, поскольку работа по сети ОИП включает в себя поддержку РДГС, как определено архитектурой РРЗС, то работа по КО в пределах РРЗС должна быть согласована с поддержкой КО в пределах УМТС.
Предварительный обзор текущей версии TR 23.907 ведет к уверенности, что он в основном достаточный, чтобы соответствовать целям сети ОИП. Обзор включает в себя следующие замечания:
- TR 23.907 включает в себя описание диалогового класса КО, в состав которого входит речь. TR 23.907 идентифицирует фундаментальные характеристики этого класса как:
Сохранить временные соотношения (изменения) между информационными объектами потока.
Диалоговый образец (строгая и низкая задержка).
Эти характеристики применимы вне зависимости от того, как передается речь: в пределах канала или как пакеты. Поэтому не было бы необходимости в модификации классов КО, определенных на текущий момент.
Ожидают, что реализация в рамках СОПНПО модели вызова согласно H.323 не повлияет ни на идентифицированные в R99 TR 23.907 технические требования к КО, общую архитектуру, ни на функции, определенные в этом документе. Тем не менее, краткое исследование будет необходимо, чтобы это проверить.
Определенные на текущее время атрибуты услуг радиодоступа к каналу-носителю будут требовать пересмотра в свете сети ОИП, но для УМТС ожидают минимальных дополнений в этой сфере. Однако для РДГС такую работу следует предвидеть. Очевидно, отображение канала-носителя на радионоситель также будет затронуто.
Вопрос обеспечения межсетевого обмена между УОНПР, способной к передаче речевых пакетов, и другими сетями требует изучения, поскольку определяет приемлемые задержки передачи речи.
7. Передача обслуживания
В настоящем разделе были обозначены темы, которые должны быть изучены и стандартизованы, чтобы поддерживать передачу обслуживания для услуг реального времени в домене КП. В настоящем разделе исследованы различные сценарии передач обслуживания, однако тот факт, что сценарий был здесь изучен, не подразумевает требование поддержки такого сценария. Требования к передаче обслуживания, относящиеся к архитектуре ОИП по версии R00 в УМТС, будут определены посредством S1, как часть работы по спецификации требований к услугам версии R00.
7.1. Перемещение ОРСК внутри IP сети УМТС R00
В пределах УМТС уже была предпринята работа для обеспечения передачи обслуживания для услуг реального времени домена КП. НСРДУ не различает канальные и пакетные услуги, а просто обеспечивает услуги в реальном и не в реальном времени, следовательно, доступна передача обслуживания внутри РЗС для услуг реального времени.
7.1.1. Требуемая поддержка внутри РРЗС
Целью ОИП архитектуры является обеспечение общей базовой сети как для НСРДУ, так и РРЗС. Описание такой работы выходит за пределы объема данного исследования, однако возможно, что РРЗС будет требовать поддержки следующих процедур:
Перемещение ОРСК.
Управляемая вспомогательной подвижной сетью передача обслуживания для пакетных услуг реального времени.
7.1.2. Передача обслуживания от ОИП УНСРД к ОИП РРЗС
Необходимость поддержки этого сценария передачи обслуживания является для ДДИ.
В таком сценарии ФУСВ будет поддерживать терминалы как в РРЗС, так и в НСРДУ. Терминал будет иметь доступ к тому же медиа-шлюзу от обеих РЗС, следовательно, в сети будет использован тот же кодек среды.
7.2. Перемещение (переадресация) ОРСК/ Передача обслуживания между доменом ОИП и доменом КК/GSM
7.2.1 Требование
Необходимость поддержки этих сценариев передачи обслуживания является ДДИ.
Ожидаемые сценарии:
Внутрисистемная передача обслуживания, где целевая система не поддерживает необходимые требования РВ для своего пакетного домена (например, внутрисистемная передача обслуживания к R97). Для выполнения такого потенциального требования на текущее время были предложены 2 решения (другие могут быть исследованы). Любое решение должно встретить следующие вопросы:
1. ПС имеет одно или более контекстов PDF для сигнализации и трафика. Поскольку ПС после HO обрабатывает домен КК, то следует ли переключать контексты PDF? Как сигнализировать к ПС, что теперь ее трафик обрабатывает домен КК? Присутствует ли H323 (H225/H245), который мог бы быть использован для такой цели?
2. Размеры сообщений мультимедиа БС могут быть значительнее, чем поддерживаемые в домене КК. Должна быть исследована возможность передачи сообщений по протоколу мультимедиа на верхний уровень радио сигнализации ГСПС КК и соединения интерфейса А, а также на интерфейс MAP/E.
3. Как УУОН определяет, что сеансы вовлекают ФУСВ?
7.2.2. Решение с ФУСВ, поддерживающей МАР/E
Следующий текст рассматривает сценарий, в котором ПО имеет по меньшей мере один активный сеанс, который вовлекает в себя ФУСВ. По приему сообщения о требуемом перемещении ОРСК, УУОН определяет, что перемещение ОРСК приводит к такому изменению УУОН, который не поддерживает услуг общего IP. Одним вариантом является заставить обслуживающий РСК удерживать сеансы до тех пор, пока сеансы, вовлекающие в себя ФУСВ, не будут прерваны, как другой вариант, УУОН должна передавать к УУОН сеансы, не использующие ФУСВ, и передавать к 3П-ЦКПС сеансы, вовлекающие ФУСВ.
Сигнализация, описанная ниже, основана на процедурах из 23.121 для перемещения ОРСК. С ее помощью показывают, что использование концепции «привязки к ЦКПС», или «опорной ЦКПС», могло бы быть применимо, чтобы поддерживать на верхнем уровне мультимедиа-сигнализацию БС, которая должна быть туннелирована обратно к ФУСВ, действующей как «Опорная ЦКПС». Однако еще возникают вопросы, касающиеся того, как удалять контекст PDP, чтобы завершить это в пределах сети.
1. После приема «Сообщение требуемого перемещения ОРСК» УУОН проверяет:
Вовлекают какие-либо сеансы в себя ФУСВ? Если так, то
Является ли E-GSN целевым УУОН?
2. УУОН сигнализирует к ФУСВ, что необходима передача обслуживания к ЦКПС. То есть посылает сообщение "Переслать перемещение ОРСК".
3. ФУСВ сигнализирует "Подготовить перемещение ОРСК" к не являющейся опорной ЦКПС, включая в состав информацию, принятую от исходного РСК.
4. Не опорная ЦКПС начинает процесс «Перемещения», обращаясь к ФУСВ, как к опорной ЦКПС. Это допускает туннелирование сообщений мультимедийного клиента БС посредством не опорной ЦКПС к ФУСВ.
5. ФУСВ командует шлюзу (GW) подготовить передачу трафика между КТСОН и не опорной ЦКПС. То есть чтобы вывести УПМУ из маршрута.
6. Успешное переключение посредством РСК каналов-носителей выводит УУОН и УПМУ из маршрута. Затем реализуют туннели GTP.
Открытые вопросы:
1. Как УУОН определяет, какие сеансы вовлекают в себя ФУСВ?
2. Как УУОН сообщает ФУСВ, чтобы запросить соединение от ЦКПС через интерфейс МАР/E? В том случае, когда ФУСВ находится во внешней сети, для УУОН может быть невозможно узнать адрес ФУСВ.
3. Для вызова от подвижной связи к КТСОН ФУСВ должна сигнализировать к шлюзу (GW) о маршрутизации трафика КТСОН к 3П-ЦКПС.
7.2.3. Межсистемная передача обслуживания с использованием ФМЭП
Способ, описанный в настоящем разделе, идентифицирует новый функциональный элемент, ISHF (ФМПО). Это изолирует МАР/E от ФУСВ. Необходима дальнейшая работа для определения того, какой из принципов следует принять: данный принцип или принцип, поддерживающий МАР/E на ФУСВ (см. раздел 7.2.2).
7.2.3.1. Общие положения
На основании требований к передаче обслуживания, приведенных в таблице 4-1, следующие сценарии межсистемной передачи обслуживания должны быть адаптированы в ОИП архитектуру.
Передача обслуживания IP сети УМТС R00 т/к сети 2П GSM.
Такие перечисленные процедуры не должны требовать изменений для терминала.
Фиг.7-1: Поддержка межсистемной передачи обслуживания Уровень адаптации
Для того чтобы поддерживать межсистемную передачу обслуживания, предложено добавление к архитектуре новой функции, названной Функцией межсистемной передачи обслуживания (ФМПО, ISHF), см. Фиг. 7-1.
Изменения/дополнения в базовой архитектуре, показанной на Фиг.7-1, включают в себя:
1. ФМПО - Функция межсистемной передачи обслуживания для передачи обслуживания между IP сетями УМТС R00 и сетями УМТС (КП, КК) и между сетями IP УМТС R00 и действующими сетями. ФМПО ответственна за процедуры передачи обслуживания сигнализации к другой базовой сети в дополнение к созданию канального соединения между исходный и целевой сетями.
2. Mx является интерфейсом между ФМПО и ШС-Р. Этот интерфейс являет собой МАР/E и его используют, чтобы сигнализировать об обмене сообщениями передачи обслуживания между сетями.
3. Му является интерфейсом между ФМПО и УПМУ. Этот интерфейс ретранслирует относящуюся к передаче обслуживания Iu, сигнализацию между НСРДУ и ФМПО. Отметим, что этот интерфейс туннелирован через УУОН.
4. Mz является интерфейсом между ФМПО и ФУСВ. Этот интерфейс используют ресурсы установки канала-носителя между исходной и целевой сетями для межсистемной передачи обслуживания.
Предполагают, что ШС-Р функция будет осуществлять взаимодействие процедур передачи обслуживания IP УМТС R00 с процедурами передачи обслуживания исходной или целевой сети, то есть что ФМПО находится в пределах ШС-Р. Возможно потребуется создание отдельной функции, которая выполняет межсетевой обмен между протоколами базовой сети, это - для ДДИ.
7.2.3.2. Передача обслуживания от сети IP УМТС R00 к/от сети 2П
На этом примере показано, как передачу обслуживания («Жесткая» передача обслуживания) выполняют от сети IP УМТС R00 в действующую сеть GSM. В примере продемонстрирована необходимая между сетями сигнализация, и сделано предположение о наличии магистрального канала-носителя между сетями. Возможны другие схемы соединения канала-носителя, но в приведенном примере к ним не обращаются. (Отметим, что все сообщения интерфейса воздушной среды не показаны для ясности схемы. В дополнение, ФУМШ и ШС-Т показаны как объединенный узел и обмен сообщениями между этими функциями опущен для ясности.)
Фиг.7-2: Передача обслуживания от сети IP УМТС R00 к GSM
Фиг.7-3: Передача обслуживания от сети IP УМТС R00 к GSM (продолжение)
Передача обслуживания IP УМТС R00 => GSM
1. После обнаружения переключения ОРСК посылает к ФМПО сообщение RANAP «Необходимо перемещение».
2. ФМПО посылает сообщение МАР/E «Подготовить передачу обслуживания» к ШС-Р.
3. ШС-Р приводит (при необходимости) сообщение «Подготовить передачу обслуживания» к соответствующему сетевому протоколу (в данном случае GSM МАР) и посылает сообщение к другой сети (ЦКПС).
Отметим: Шаги 4 и 5 следуют нормальным процедурам GSM и показаны только для ясности.
6. Как только начальная процедура в ГСПС ЦКПС/ОБС завершена, ЦКПС возвращает сообщение МАР «Подготовить ответ передачи обслуживания» к ШС-Р.
7. ШС-Р преобразует (если необходимо) к протоколу МАР/E и посылает результирующее сообщение «Подготовить ответ передачи обслуживания» к ФМПО.
8. ФМПО инициирует процедуры, предназначенные для образования ресурсов канала-носителя между сетями. В данном случае образуют магистральный канал. ФМПО посылает сообщение CONNECT (Соединить) к ФУСВ для инициации вызова установки канала-носителя.
9. ФУСВ посылает CONNECT к шлюзу канала связи (ФУМШ, ШС-Т для простоты показаны объединенными) для создания исходящего вызова к ЦКПС.
10. Шлюз канала связи цепи посылает сообщение IAM ППИУ к ЦКПС.
11. ЦКПС отвечает сообщением подтверждения (АСК).
12. ФМПО отвечает на начальный запрос от ОРСК посылкой к ОРСК сообщения RANAP «Команда на перемещение».
13. Через существующее соединение ОРСК посылает к ПО сообщение РСК «Команда передачи обслуживания» («Жесткая» передача обслуживания).
(Пункты 14-16 в тексте отсутствуют)
Параметры: тип передачи обслуживания.
Отметим: Процедуры, относящиеся к синхронизации и т.п., с GSM BSS не показаны.
Отметим: Этапы 14-16 следует нормальным процедурам GSM и показаны только для ясности.
17. Обнаружение ПО в пределах зоны обслуживания (покрытия) GSM приводит тому, что ЦКПС посылает к сети IP УМТС R00 (ШС-Р) сообщение МАР «Запрос посылки сигнала окончания».
18. ШС-Р пересылает «Запрос посылки сигнала окончания» к ФМПО.
19. ФМПО инициирует освобождение ресурсов, распределенных формирователем ОРСК (Команда «Освободить Iu»).
20. От ЦКПС посылают ответ ППИУ к шлюзу канала связи.
21. «Соединить» возвращают к функции ФУСВ.
22. «Соединить» передают обратно к ФМПО.
23. Внутри УМТС освобождают предварительно распределенные ресурсы канала-носителя (например, используя протоколы RANAP и ALCAP [ALCAP не показан]) ( Освобождение Iu завершено).
24. Процедура выведена из точки зрения УМТС посредством ФМПО, посылающей сообщение МАР/E «Послать ответ сигнала окончания» (это сообщение не посылают до окончания вызова).
25. ШС-Р пошлет сообщение МАР «Послать ответ сигнала окончания» к ЦКПС.
7.3. Области дальнейшего исследования
Перечисленные ниже области могут потребовать дальнейшего исследования.
Установка/управление каналом-носителем между сетями в течение передачи обслуживания.
Привязка канала-носителя в сети IP УМТС R00.
Поддержка АПВС.
«Мягкая» передача обслуживания между РСК.
Обмен от СРД к СРД при одном типе организации потока данных.
Обмен от СРД к СРД при различных типах организации потока данных.
8. Вопросы радиосвязи
Отметим: Этот раздел требует поддержки группы СРД.
8.1. Общие положения
1) Определение интерфейса БС-СРД
(a) Рассмотрено функциональное разделение между БС и СРД - новой сетью радиодоступа, называемой «Сетью радиодоступа РУОНПР» (РРЗС). Интерфейс между сетью радиодоступа, как, например, РРЗС или НСРДУ и БС, должен быть определен/расширен и должен позволять различным технологиям интерфейса среды воздушной радиосвязи осуществлять доступ к БС. Подробное функциональное разделение между БС и СРД требуют дальнейшего исследования.
(b) Влияние на существующие реализации и развертывания УОНПР/РУОНПР/НСРДУ
(c) Переход сценариев 2П к версии 99 (BSS не является основанным на IP) и к версии 2000 (к сети ОИП)
(d) Оценка стека протоколов (включая в состав оценку управления и пользовательских уровней от ON к СРД и к ПС)
2) Архитектура РРЗС (Ссылка на SMG2)
(a) Элементы эталонной модели сети РРЗС, стек протоколов и логические или функциональные элементы.
(b) Функциональное разделение между элементами.
(c) Определение взаимодействия между элементами.
(d) Влияние на существующие развертывания УОНПР/РУОНПР (КБС, БУП, и БС) и стратегии перехода.
3) Архитектурные расширения НСРДУ.
(a) Идентификация необходимых расширений.
4) Передача обслуживания в реальном времени для домена с коммутацией пакетов.
(a) Вопросы РРЗС (Ссылка на SMG2).
(b) Вопросы НСРДУ.
5) Поддержка КО.
(a) Оценивание перспективы специального S2 КО для поддержки данных реального времени.
(b) Способ и средства сигнализации.
(c) Вопросы БС.
(d) Согласование УОНПР с КО УМТС
(e) Реализация КО в радиолинии связи.
6) Вопросы радиосвязи (E)УОНПР (Ссылка на SMG2).
(a) Поддержка реального времени, включающая в состав передачу обслуживания и КО.
(b) Спектр вопросов эффективности/производительности (например, статистическое мультиплексирование и кодирование источника/канала).
(c) Расширения УРЛ/УДС.
(d) Следует рассмотреть воздействие различных сценариев развертывания (например, доступность спектра) и смешение трафика, как, например, речи и данных, на эффективность спектра.
7) Вопросы радиосвязи UTRA УНСРД
(a) Поддержка пакетных данных реального времени, включающая в себя передачу обслуживания и КО, - проверка достоверности и возможное расширение.
(b) Эффективность/производительность радиосвязи (например, статистическое мультиплексирование и кодирование источника/канала).
(c) При необходимости расширения УРЛ/УДС.
(d) Следует рассмотреть воздействие различных сценариев развертывания (например, доступность спектра) и смешивание трафика, как, например, речи и данных, на эффективность спектра.
Отметим: пункты строк, относящиеся к УРЛ/УДС (разделы 6(c) и 7(c)), могут включать в себя:
Расширенное распределение радиоресурсов.
Определения канала-носителя радиодоступа (т.е. определения для различных классов трафика маршрута через стек протоколов и канала-носителя, подлежащего использованию).
Классификация потока (например, отображение пользовательского трафика на соответствующий канал-носитель радиодоступа).
Расширение протокола РУОНПР для поддержки услуги реального времени и управление КО (например, быстродействующие схемы распределения каналов).
8.2. Оптимизация линии воздушной радиосвязи для IP реального времени
8.2.1. Введение
Во ОИП архитектуре фундаментальной целью является поддержка для мобильного терминала трафика, основанного на IP и осуществляемого в реальном времени и в не реальном времени, достигая при этом эффективности спектра и устойчивости к ошибкам. В случае передачи речи в реальном времени эффективность спектра и устойчивость к ошибкам имеют базовый уровень производительности, определяющийся текущими системами сотовой связи. Есть также базовый уровень КО речи. Естественно ожидать, что ОИП архитектура должна соответствовать существующему базовому уровню речевых услуг. Вопрос заключается в том, как согласовать цели эффективности спектра и устойчивости к ошибкам и существующий базовый уровень для речевых услуг реального времени при применении парадигмы ОИП к системам сотовой связи.
Для основанного на IP мультимедиа реального времени протокол RTP преимущественно используют на верхнем уровне UDP/IP. Размер объединенных заголовков IP/UDP/RTP является равным по меньшей мере 40 байтам для IPv4 и по меньшей мере 60 байтам для IPv6, тогда как речевая полезная нагрузка - короткая, обычно короче заголовка IP/UDP/RTP. Понятно, что если заголовки были посланы "как есть" по интерфейсу среды воздушной радиосвязи, чтобы соответствовать чистой ОИП парадигме, то он не достигнет и даже не приблизится к базовому уровню эффективности спектра существующих речевых каналов. Необходимы некоторые способы адаптации заголовка, посредством которых преобразование, применяемое к заголовкам IP/UDP/RTP, уменьшит их размер перед передачей через интерфейс воздушной среды радиосвязи, и обратное преобразование, применяемое после перемещения по интерфейсу воздушной среды радиосвязи для восстановления значений и размера исходного заголовка. Сокращение размера заголовка достигают посредством устранения избыточности в исходной кодированной информации заголовка и/или удалением информации поля заголовка и в силу этого потерей функциональности.
Влияние на прозрачность и устойчивость к ошибкам должно быть полностью понято для того, чтобы разработать соответствующие способы адаптации (прозрачность для данного поля заголовка определяют как свойство, посредством которого значение после преобразования/обратного преобразования является тем же, что и в исходном заголовке).
Этот раздел изучает диапазон возможных способов техники и предлагает два способа адаптации, расщепление заголовка и сжатие заголовка. Два способа должны быть дополнительно исследованы в отношении устойчивости к ошибкам, качеству речи и прозрачности IP.
8.2.2. Адаптация пользовательского уровня
Далее идут ссылки к функциональности, которую осуществляют преобразование/обратное преобразование в качестве Адаптации пользовательского уровня (АПУ), и исследование диапазона возможных способов адаптации наряду с их «за» и «против».
8.2.2.1. Полная непрозрачность (адаптации нет)
АПУ не имеет знаний о внутренней структуре заголовков или полезной нагрузке, и отсутствует какое-либо преобразование заголовков IP/UDP/RTP, которые посылают полностью по интерфейсу воздушной среды радиосвязи. Защиту от ошибок применяют равномерно ко всем битам заголовка, и равномерно ко всем битам полезной нагрузки. Часть, относящаяся к заголовку, вероятно потребует более сильной защиты от ошибок, чем полезная нагрузка, поскольку потеря заголовка потребует отвергнуть соответствующий пакет, и никакое сокрытие или смягчение ошибок не может быть применено к заголовку. Этот способ достигает полной прозрачности, которая позволяет поддерживать протоколы такие, как DPSEC на сквозной основе. Очевидным «против» являются вызываемые заголовками высокие перегрузки, которые приводят к низкой эффективности спектра.
8.2.2.2. Непрозрачность полезной нагрузки (адаптация только заголовка)
В таком случае АПУ требует знания только внутренней структуры заголовка IP/UDP/RTP, но не полезной нагрузки. Адаптируют только заголовки, либо сжатием заголовка, либо расщеплением заголовка.
8.2.2.2.1. Сжатие/распаковка заголовка
Заголовки IP/UDP/RTP сжимают перед передачей по интерфейсу воздушной среды радиосвязи и распаковывают на принимающей стороне. Подобно предыдущему, заголовки требуют более сильной защиты от ошибок, чем полезная нагрузка. Наиболее хорошо известным алгоритмом сжатия заголовков является алгоритм Van Jacobson (RFC 1144, Сжатие TCP/IP заголовков для низкоскоростных последовательных линий связи). В общем случае сжатые заголовки более уязвимы к ошибкам, чем несжатые заголовки. Проверенные существующие стандартизованные алгоритмы оказались менее эффективными для связей с потерями, какими является радиоинтерфейс.
Преимущества сжатия заголовков IP/UDP/RTP является тем не менее очевидным, поскольку значительно сокращает необходимую перегрузку на пакет. При эффективной схеме сжатия заголовка заголовки IP/UDP/RTP могут быть сжаты до 2 байтов.
В будущем будут разработаны новые схемы сжатия заголовков, адаптированные для характеристик надежности сотовой радиосвязи. Такие схемы, адаптированные к среде радиосвязи, смогут быть способными сжимать заголовки IP/UDP/RTP до 2 байтов. Одним из примеров среди прочих была бы схема, предложенная в настоящее время для разработки в КИПСИ, и в которой сжатый заголовок несет информацию о контрольной сумме, вычисленной для заголовка перед его сжатием. Это обеспечивает надежный способ обнаружения и исправления ошибок и повышает устойчивость к ошибкам.
Общим недостатком большинства схемам сжатия заголовка является несовместимость со сквозной безопасностью (IPSEC) и управлением полосой частот пропускания, поскольку сжатые заголовки имеют переменный размер.
Требования и критерии оценивания для схем сжатия заголовка, которые должны быть использованы для радиоинтерфейсов, суммированы в таблице 8-1.
На Фиг.8-1 показана концептуальная схема сжатия заголовка, используемая в сочетании с нижними уровнями (протоколов) сотовой связи. Речь использована в качестве примера. Нижние уровни могут выполнять перемежение и кодирование канала. Для упрощения воздействие перемежения и кодирования канала на поток битов, передаваемый через интерфейс воздушной среды радиосвязи, не показан. Воздействие возможного уровня мультиплексирования линии связи с другими потоками трафика также не показано. Существуют базированная на ПС точка АПУ и базированная на сети точка АПУ. Базированная на ПС точка АПУ действует как «сжиматель» заголовка и «распаковщик» заголовка для соответственно восходящей и нисходящей линий связи, тогда как базированная на сети точка АПУ действует как «распаковщик» заголовка и «сжиматель» заголовка для соответственно восходящей и нисходящей линий связи.
Требования к сжатию заголовка описаны в нижеследующей таблице. В каждом случае приведено некоторое обоснование требования.
Требования к сжатию заголовков
производительности/спектра
Фиг.8-1: Сжатие заголовка
Таблица 8-1: Требования к сжатию заголовков
8.2.2.2.2. Расщепление/восстановление заголовка
Заголовки IP/UDP/RTP расщепляют перед передачей по интерфейсу воздушной среды радиосвязи и восстанавливают на принимающей стороне. По существу передают только полезную нагрузку, но необходима передача некоторой дополнительной, относящейся к заголовку информации, чтобы иметь возможность восстановления заголовка. Степень достигнутой прозрачности заголовка является переменной, зависящей от количества относящейся к заголовку информации, которую желательно передать. Никакая защита заголовка от ошибок не нужна, когда информацию заголовка полностью удаляют. Однако информация, необходимая для восстановления заголовка, требует наличия заголовка по меньшей мере для некоторых пакетов. Когда полезная нагрузка имеет постоянный размер, управление полосой пропускания частот фактически отсутствует, поскольку полезные нагрузки могут быть переданы по каналу с постоянной битовой скоростью. Канал с постоянной битовой скоростью также устраняет проблемы КО (задержку и искажение сигнала). Как и выше по тексту, сквозная безопасность не может быть применена.
На Фиг.8-2 показана концептуальная схема расщепления заголовка, используемая применительно к нижним уровням сотовой связи. Передача речи использована в качестве примера. На нижних уровнях можно выполнить перемежение и кодирование канала. Для упрощения воздействие перемежения и кодирования канала на поток битов, передаваемый через интерфейс воздушной среды радиосвязи, не показано. Воздействие возможного уровня мультиплексирования линии связи с другими потоками трафика также не показано. Существуют базированная на ПС точка АПУ и базированная на сети точка АПУ. Базированная на ПС точка АПУ действует как «распределитель» заголовка и «восстановитель» заголовка для соответственно восходящей и нисходящей линий связи, тогда как базированная на сети точка АПУ действует как «восстановитель» заголовка и «распределитель» заголовка для соответственно восходящей и нисходящей линий связи.
Фиг.8-2: Расщепление заголовка
8.2.2.3. Отсутствие непрозрачности (полная адаптация)
АПУ знает структуру заголовков и полезной нагрузки. Заголовки могут быть сжаты или расщеплены. В дополнение, передача полезной нагрузки оптимизирована посредством способов таких, как неравноценная защита битов, кодирование канала и ошибок, оптимизированное для структуры полезной нагрузки и т.п.
8.2.3. Применение к сети ОИП
Ожидают, что сеть ОИП обеспечит в реальном времени услуги канала-носителя, предназначенные для того, чтобы передавать:
- Основную разговорную речь (услуга, эквивалентная передаче речи в текущих системах сотовой связи).
- Мультимедиа реального времени (включает в состав речь, которую рассматривают как компонент мультимедиа).
8.2.3.1. Основная речь
Для основной речи особое значение придают соответствию и, если возможно, превышению базового уровня традиционной сотовой связи с точки зрения эффективности спектра, устойчивости к ошибкам и качества речи. Традиционные системы сотовой связи достигают такой базовый уровень, используя хорошо известные способы, как, например, неравноценная защита битов, кодирование канала и ошибок, оптимизированное для структуры полезной нагрузки, и т.п. В дополнение, кадры речевых данных не несут каких-либо затрат на заголовок (в понимании IP). В системе ОИП предлагают определять канал-носитель "Базовой речи", специализированный для разговорной речи, и возможно другой носитель с такими же характеристиками. Базовая речь будет использовать оптимизацию полезной нагрузки и неравноценную защиту битов полезной нагрузки подобно традиционной сотовой связи. Упаковка большего количества речевых фреймов в один пакет улучшит относительные потери, но за счет дополнительной задержки, которая оказывает отрицательное воздействие на качество речи. Передача относящейся к заголовку информации и/или сжатого заголовка потребует строгой защиты от ошибок.
Существуют два варианта для достижения требуемых характеристик Базовой речи:
Расщепление заголовка: в качестве минимума, расщепление заголовка для основной речи должно достичь прозрачности для статических полей IP/UDP/RTP (которых неизменны в течение вызова) и меток времени RTP и последовательного номера RTP. Такой канал-носитель соответствует приведенному выше случаю полной адаптации при расщеплении заголовка.
Сжатие заголовка, адаптированное к характеристикам радиосвязи: используя надежные схемы сжатия заголовка потери на один пакет сведены до 2 байтов. Такой случай также должен соответствовать приведенному выше случаю полной адаптации со сжатием заголовка.
Дополнительные способы оптимизации могут быть предложены для дальнейшего повышения эффективности спектра. Следует оценить два варианта и конкретные алгоритмы в соответствии с критериями таблицы 8-1 главы 8.1.2.1.
8.2.3.2. Мультимедиа реального времени
Мультимедиа реального времени является новой услугой, которая отсутствует в традиционных системах сотовой связи 2П. Предложен новый канал-носитель. Для такого канала-носителя прозрачность для всех полей IP/UDP/RTP является решающей. Под ограничением «прозрачность» есть намерение оптимизировать эффективность спектра и устойчивость к ошибкам, но в отличие от речи отсутствует базовый уровень, подлежащий использованию в качестве целевого. Требование прозрачности естественно ведет к выбору сжатия заголовка в качестве адаптации на пользовательском уровне. Полезная нагрузка будет иметь некоторую защиту от ошибок и сжатый заголовок будет иметь даже более сильную защиту. Должна быть исследована способность обеспечивать неравноценную защиту битов полезной нагрузки также и для этой услуги. Такой канал-носитель соответствует адаптации заголовка только для приведенного выше случая со сжатым заголовком. Конкретные алгоритмы, применимые к мультимедиа реального времени, должны быть оценены в соответствии с критериями таблицы 8-1 главы 8.1.2.1.
8.2.3.3. «Чистый» IP
«Чистая» IP услуга может быть предоставлена, чтобы обеспечить сквозные протоколы, как, например, IPSEC. Для того чтобы достичь такого обеспечения, канал-носитель не делает никакой адаптации и соответствует приведенному выше случаю «Отсутствие адаптации». Адаптацию заголовка можно также применять для «чистого» IP. Конкретные алгоритмы для адаптации заголовка должны быть оценены в соответствии с критериями таблицы 8-1 главы 8.1.2.1.
8.2.4. Выводы
Пакеты IP/UDP/RTP требуют адаптации к радиолинии для согласования эффективности спектра и требований устойчивости к ошибкам систем сотовой связи. Должно быть исследовано, может ли единственная схема одновременно и полностью удовлетворять вышеуказанным требованиям и прозрачности IP. Альтернативой для единственной схемы является градация схем, специализированных для конкретного типа приложения. Приложения могут затем использовать различные типы каналов-носителей, оптимизированных для конкретных текущих потребностей.
Каналы-носители реального времени могут быть разбиты на категории, рассматриваемые с точки зрения сжатия заголовка, на базовую речь (БР) и мультимедиа реального времени (ММРВ). Канал-носитель БР предназначен для передачи речевых данных в качестве услуги, эквивалентной подобной в традиционных системах сотовой связи. Канал-носитель ММРВ предназначен для передачи трафика общего мультимедиа, в состав которого может входить речь. В дополнение, «чистая» IP услуга может быть предложена для поддержки приложений, которые требуют полной прозрачности.
БР будет использовать расщепление заголовка или сжатие заголовка с неравноценной защитой битов в полезной нагрузке.
ММРТ будет использовать сжатие заголовка с равной защитой битов в полезной нагрузке. Возможность поддержки неравноценной защиты битов в полезной нагрузке подлежит исследованию.
«Чистая» IP услуга будет поддерживать транспорт данных без преобразования заголовка. Сжатие заголовка должно также быть возможно для «чистого» IP. «Чистый» IP использует равноценную защиту битов в полезной нагрузке. Во всех случаях заголовок (если присутствует) требует сильной защиты от ошибок.
9. Управление Вызовом
9.1. Терминология для управления вызовом
Терминология в данном разделе представляет используемую в настоящем документе терминологию, которая является новой или была изменена по сравнению с определенной для R99. Терминология, определенная в настоящем разделе, не была объектом реальной дискуссии и, следовательно, не может считаться принятой к соглашению. Этот раздел должен быть согласован с терминологией, использованной в R99. Терминология по версии R99 должна быть использована до тех пор, пока не будет введено новое или изменено существующее понятие. Изменения в терминологии, определяемой в S1, требуют соглашения S1.
Данный раздел определяет общее множество терминов, на которых основан настоящий документ. Последующий перечень терминов является первой попыткой определения некоторой конкретной терминологии.
Терминология, определенная в настоящем разделе, не была согласована с существующей терминологией ПП3П и такое согласование должно быть сделано. Более того, в ПП3П еще не определены все термины, которые необходимы для сети ОИП.
1. Профиль, или параметры, доступа: содержат информацию о профиле подписки, соответствующую конкретному каналу-носителю сети. Как пример, параметры E-УОНПР плюс свойства радиоканала-носителя (например, КО), к которым пользователь может иметь доступ, являются профилем доступа. Относящаяся к конкретному доступу информация роуминга, используемая для доступа к действующим сетям и от таких сетей, является частью профиля доступа. Как пример, для терминалов КК параметры доступа содержат информацию о разрешенных LA, о данных безопасности для аутентификации.
2. Профиль, или параметры, услуг сетей ОИП по Версии 2000: содержат данные подписки на услугу, соответствующие услугам сети ОИП по Версии 2000, на которые подписался пользователь. Как пример, профиль услуги содержит пользовательский идентификатор, пользовательские псевдонимы, информацию о пользовательском временном положении (например, указатель на текущий обслуживающий домен), указание мультимедийных услуг и возможностей, на которые подписался пользователь, переключатели, или триггеры, услуг, статус вспомогательных услуг и т.п.
3. Пользовательский профиль: объединение одного или более профилей доступа с ни одним, одним или несколькими профилями услуг сетей ОИП и роуминга. Пользовательский профиль поддерживают в ДСА. (ДДИ)
4. Поток PDP: это контекст PDP без ограничения на то, что различный IP адрес должен быть присвоен различным контекстам PDP. Различение потоков PDP основано на типе протокола (например, TCP, UDP и т.п.) и номере порта. (ДДИ)
5. Сеть каналов-носителей: это множество сетевых элементов, которые обеспечивают пользователя средствами для соединения с обслуживающим/домашним доменом, чтобы использовать услуги или средства сети, в которой пользователь осуществляет роуминг и получает доступ к домашнему домену или к услугам других сетей. Примерами сетей каналов-носителей являются:
- Е-УОНПР вместе с одной или более различных СРД.
- Кабельная сеть доступа и т.п.
6. Домен: домен является логической ассоциацией сетевых элементов. Домен может содержать произвольное количество ДСА, ФУСВ и ФМР. Домен может быть Домашним доменом для некоторых пользователей (для тех, профиль подписки которых хранится в ДСА конкретно в этом домене) и Обслуживающим доменом для других пользователей (для тех, профиль подписки которых хранится в ДСА в отдельном домене). Домен может соединить с множеством сетей каналов-носителей. (ДДИ) Цель введения концепции домена в версию 00 заключается в том, чтобы добиться независимости доступа в БС, поддержать адреса БК (NAI, Безадресная команда, БК), расширяемость, дополнительные услуги и требуемые серверы (например, межсетевого обмена Email/ФУСВ), допустить использование ССИ и справочников для преобразования (адресов). Концепция домена уже обеспечивает связующее звено для многих полезных услуг и функциональностей. Домен является логической областью, которая указывает систему или зону. Домен используют, чтобы связать услуги и серверы, имеющие общий идентификатор, для целей преобразований. Домен используют аналогично ключу в базах данных для того, чтобы получить сетевые адреса узлов для соответствующих услуг, ассоциированных с доменом. Фактическое местоположение узла, поддерживающего эти услуги, не ограничено доменом каким либо способом. Термин домен, используемый в настоящем документе, ссылается на определение домена, сделанное в ССИ.
Открытый вопрос: использование термина домен, домашний домен и обслуживающий домен требуют дальнейшего уточнения и анализа.
7. Домашний домен: им является домен, который содержит ДСА. В частности, Домашним доменом пользователя является домен, содержащий ДСА, который хранит пользовательский профиль. Домашний домен может содержать или не содержать домашнюю ФУСВ, ФМР или логику услуги. Домашний домен:
обеспечивает и осуществляет сопровождение пользователя и пользовательских данных подписки в ДСА для пользователя, принадлежащего домену;
поддерживает также доступ независимых пользователей и пользовательских профилей, как например, закладки браузера и перечни (номеров) телефонов;
пользователь поставляет и обновляет текущий визитный обслуживающий домен пользовательским профилем;
сохраняет информацию о маршрутизации и мобильности, которая дает возможность доставки услуги пользователям и роуминг пользователей, осуществляемый вне и внутри домашней сети;
поддерживает соглашения о роуминге и соглашения об уровне услуг с другими сетями;
домашний домен, когда он содержит домашнюю ФУСВ, «виден» из инициирующей (запрашивающей) сети как начальный пункт завершения;
может собирать и объединять данные учета оплаты услуг.
Другие функции являются ДДИ.
8. Обслуживающий Домен:
сохраняет параметры роуминга так, как они приняты от домашнего домена;
обеспечивает услуги или доступ к услугам в домашнем домене (в соответствии с возможностями терминалов и соглашением об уровне услуг для различных операторов связи домена) насколько возможно близко к (лозунгу) "смотри, прикасайся и ощущай";
сохраняет информацию о маршрутизации и мобильности, которая дает возможность доставки услуги пользователям, осуществляющим роуминг в обслуживающем домене;
по выбору осуществляет сбор данные для учета оплаты услуг и статистики;
может обеспечить локальные услуги, как например, услуги и информация, основанные на местоположении (например, реклама, объявления оператора связи о локальных событиях, и т.п.);
поставляет необязательные (дополнительные) ресурсы такие, как устройства для конференций, управление вызовом мультимедиа и т.п. (Ресурс может быть обеспечен в домашней сети).
Домашний домен может действовать в качестве обслуживающего домена, когда пользователь регистрирован в домашнем домене. (ДДИ)
9. Сети ОИП по Версии 2000: согласно Версии 2000 сети ОИП содержат следующие логические компоненты:
Один или более домен(ов);
Произвольное количество сетей каналов-носителей;
Возможность соединения с одним или более ФУМШ и МШ.
Ни одного, один или более серверов ЦКПС/МЦКПС.
10. Домашняя сеть (ДС): при рассмотрении конкретного пользователя, Домашняя сеть составлена из ни одного, одного или более обслуживающих доменов, любого количества сетей каналов-носителей, ни одного, одного или более ФУМШ/МШ, и домашнего домена для этого конкретного пользователя. (ДДИ)
11. Обслуживающая сеть (ОС): при рассмотрении конкретного пользователя, Обслуживающая сеть составлена из ни одного, одного или более обслуживающих доменов и одного или более сетей носителей, ни одного, одного или более ФУМШ/МШ, и не содержит домашний домен этого конкретного пользователя. (ДДИ)
12. Домен логики услуги: включает себя следующие функции:
содержит существующие возможности услуг телекоммуникации (т.е., ПУО для ИС);
содержит возможности типа услуг WAP, основанных на Web;
допускает простой доступ пользователей к услугам (уведомления о новых услугах, активизации/деактивизация услуг в сети, возможности для оплаты обновления для новых услуг, и т.п.);
обновляет данные профиля в домашнем домене в случае модификаций пользователем или поставщиком оператора Домена логики услуг;
предоставляет доступ или возможности достижения другого Домена логики услуг;
некоторые услуги, основанные на местоположении, также могут находиться в Домене логики услуг.
Домен логики услуг может иметь тесную связь с Домашней сетью для того, чтобы управлять/оплачивать/обеспечивать возможность применения услуги, установленную единообразно для пользователей. В частности, если ФУСВ обрабатывает переключение услуг, то Домен логики услуг и Домашний домен могут быть обеспечивающими как пользовательский профиль, так и профиль подписки для ФУСВ в согласованном/прозрачном виде. Домен логики услуг может также быть автономным, то есть независимым от местоположения сети. (ДДИ) Остается для дальнейшего исследования, может или не может ФУСВ быть логически связанной с доменом логики услуг.
13. Домашний пользователь: является пользователем домашней сети, имеющим подписку в домашнем домене. Пользователя считают домашним пользователем, когда пользователь находится в обслуживающем домене в своей домашней сети. Пользователь может быть или не быть расположен в домашнем домене.
14. Пользователь, осуществляющий роуминг: является пользователем, находящимся вне его Домашней сети и обслуживаемым в обслуживающей сети. (ДДИ)
Фиг.9-1: Моделирование сети в доменах
15. Действующая сеть: действующая сеть может быть:
основанными на SS7 сетями (например, СОПНПО, КТСОН и ЦСИУ), а также основанными на CAS сетями;
сетями УОНПР. (ДДИ)
16. Сеть IP мультимедиа: она является внешней IP сетью с поддержкой мультимедийных услуг реального времени (с использованием протоколов H.323 и/или SIP) и включает сетевые элементы SIP/H.323 и терминалы, и возможно, шлюзы для интерфейса с Версией 2000 сетей ОИП. (ДДИ)
17. Обслуживающая ФУСВ (ФУСВ-О): это ФУСВ в Обслуживающем домене, с помощью которой пользователя регистрируют и которая обеспечивает услуги в зависимости от профиля услуг(и), полученного от Домашнего домена пользователя. (ДДИ)
18. Домашняя ФУСВ (ФУСВ-Д): Домашней ФУСВ является ФУСВ в Домашнем домене или Частном домене. Домашнюю ФУСВ ассоциируют с пользователем во время подписки и, если пользователь идентифицирован псевдонимами, это может потребовать преобразования в IP адрес (например, логические имена, преобразуемые посредством ССИ), транспортный адрес Домашней ФУСВ будет обеспечен как преобразование псевдонимов. (ДДИ)
9.2. Предположения
Следующие предположения были рассмотрены при разработке моделей роуминга, описанных в настоящей версии документа.
1. Требования к способам адресации будут основаны на требованиях и способах, указанных 3GPP в 3G TR 22.975 и 3G TS 33.003.
2. Будут рассмотрены разрешение/запрещение вызова и переадресация вызова. Подробности разрешения вызова (например, аутентификация и КО) в настоящем документе обсуждены не будут.
3. Будет рассмотрена переадресация входящих запросов на передачу речи или данных, адресованных к пользовательскому справочному номеру, в течение периодов перенастройки национальных номерных планов. Вероятно, будет предусмотрено не окончательное решение (например, перенаправление вызовов на основании баз данных).
4. Специализированный поток PDP (называемый потоком PDP Сигнализации), отличный от потоков PDP, передающих среду БПД, принят для того, чтобы передавать сигнализацию между ПО и ФУСВ (например, установка вызова, сигнализация внутри вызова, как, например, запросы на мигание). Поток PDP сигнализации не требует наличия IP адреса, отличающегося от адреса какого-либо из потоков PDP, передающих среду.
5. Пользовательские профили сохраняют в базе данных/на сервере в домашнем домене.
6. В случае роуминга пользовательский профиль в домашней сети должен быть опрашиваемым обслуживающей сетью по меньшей мере при регистрации и часть пользовательского профиля может быть временно сохранена в обслуживающей сети.
7. Архитектура роуминга будет оптимизирована в предположении, что IP адреса будут распределяться динамически.
8. Никаких новых требований не должны устанавливаться для действующих сетей (например, КТСОН, 2П СОПНПО) и сетей IP мультимедиа для взаимосвязи с сетями ОИП по Версии 2000. Сети ОИП по Версии 2000 должны гарантировать способность к взаимодействию с существующими действующими сетями и сетями IP мультимедиа. В том случае, когда повторно используют 2П ОРМ (например, УОНПР ОРМ) для того, чтобы содержать данные для пользователей сети ОИП по Версии 2000, 2П ОРМ будет модернизирован для поддержки пользователя сети ОИП по Версии 2000 и интерфейсы сети возможно потребуют модернизации.
10. Процедура регистрации ПС логически состоит из регистрации уровня канала-носителя (например, подсоединения УОНПР) и, если указано/допустимо профилем подписки ПС, то регистрации уровня приложения. Регистрацию ПС выполняют, как пример, при включении питания ПС.
11. Процедура регистрации уровня канала-носителя влечет за собой регистрацию с узлом УОНПР в соответствии с процедурами, производными от УОНПР.
12. Процедура регистрации уровня приложения влечет за собой регистрацию с обслуживающим сервером ФУСВ/ЦКПС для того, чтобы информировать сервер ФУСВ/ЦКПС о присутствии ПС и позволить серверу ФУСВ/ЦКПС извлекать пользовательскую информацию из ДСА.
13. Рассматривают, что регистрацию уровня каналов-носителей и регистрацию уровня приложения будут осуществлять две отдельные процедуры. Завершение регистрации уровня канала-носителя может запустить в ПО активизацию потока PDP сигнализации в качестве возможного средства поддержки процедуры регистрации уровня приложения.
14. Местоположение ПС отслеживают на уровне УОНПР, используя управление мобильностью, реализуемое УОНПР, и мобильность пользователя отслеживают на уровне приложения посредством специализированной процедуры, предназначенной для обновления пользовательской информации, поддерживаемой сервером ФУСВ/ЦКПС и, возможно, информацию о местоположении содержит ДСА.
15. ДСА отслеживает мобильность пользователя в терминах текущего сервера ФУСВ/ЦКПС или обслуживающего домена.
16. Поддержка коллективных сеансов передач речи и данных (включая в состав возможность для пользователя или логики услуги динамического добавления или удаления пользователей из активного сеанса связи) не рассмотрена в настоящей версии данного документа.
17. Должны существовать соглашения по роумингу (статические или динамические) между взаимодействующими операторами связи.
18. Между операторами сети определены (статические или динамические) соглашения (СУУ) об уровне услуг, чтобы гарантировать согласованный уровень услуг (например, сквозное КО, безопасность и т.п.)
19. Все сетевые компоненты, которые требуют анализа адресов и преобразования адресов для маршрутизации завершающих вызовов (например, ФУСВ, сервер ЦКПС, ФУМШ), способны осуществлять преобразования или имеют доступ к согласованным базам данных преобразований или к ДСА для того, чтобы решить вопросы маршрутизации/завершения вызова.
20. Существуют функции ЭиТО для соединения между собой различных компонентов сети ОИП Версии 2000, давая возможность каждому компоненту узнать как адресовать/осуществлять доступ к любому другому компоненту в пределах домена сети.
21. Функции ЭиТО существуют для того, чтобы сделать обеспечивающие сетевые профили (например, 800 переключений, тональная информация) в любой момент доступными в каждом домене.
22. Для того чтобы оптимизировать пользовательский уровень, обслуживающая УПМУ будет предпочтительно расположена в обслуживающей сети.
23. Профиль услуг (статус подписки и активизации) и переключения услуг также поддерживают посредством ДСА и/или обновляют посредством ДСА на сервере ФУСВ/ЦКПС.
24. Предполагают, что маршрутизируемая ФУСВ сигнализация вызова предназначена для услуг реального времени.
25. Каждую ФУСВ ассоциируют с одним или более ФМР, и каждый ФМР может быть управляем более чем одной ФУСВ. Для ясности, если используют терминологию H.323 для описания ФМР, то БУС является частью ФМР. ФМР может быть расположена в домашней сети (когда домашняя ФУСВ управляет текущим вызовом) или в обслуживающей сети (когда обслуживающая ФУСВ управляет текущим вызовом).
26. Некоторые функции домашней ФУСВ необходимы во всех сценариях роуминга для того, чтобы поддержать:
входящие вызовы, адресованные к СН от других сетей ОИП Версии 2000 или от сетей IP мультимедиа, оптимизированной маршрутизацией (то есть вызовами, не маршрутизируемыми через КТСОН);
входящие вызовы от других сетей ОИП Версии 2000 или от сетей IP Мультимедиа, отправленные с ЛИ (логическим именем);
реализацию вспомогательных услуг и функций, подобных фильтрации входящих звонков для завершенных вызовов (например, Безусловная пересылка вызова).
9.3. Роуминг внутри сетей ОИП
Далее описан ряд сценариев роуминга.
Примечание Редактора: отметим, что сетевые интерфейсы и имена, показанные на схемах 6.4 до 6.7, могут быть не всегда правильными.
9.3.1. Модель вызова
Модель вызова, описанная нижеследующими утверждениями, была принята в настоящем документе:
Вызовы от/через КТСОН маршрутизируют к ФУМШ с возможностью соединения с Домашней сетью, соответствующей вызвавшему (набранному) СН.
Вызовы от сети ОИП Версии 2000 к различным сетям ОИП Версии 2000, отправленные с СН, могут быть оптимизированы (т.е. не маршрутизированы через КТСОН) только, если отправляющая сеть ОИП Версии 2000 знает номерной план целевых сетей ОИП Версии 2000 и может маршрутизировать вызов непосредственно к целевым сетям ОИП Версии 2000, не выходя из домена IP. Дополнительная оптимизация может быть возможной, если сеть, из которой вызов отправлен, имеет также доступ к ДСА той сети, к которой вызов направлен и соответствующую отправленному СН. Такое же применимо к вызовам от сети IP мультимедиа к сети ОИП Версии 2000, отправленным с СН. (ДДИ)
Предположим сценарий 1, для входящих вызовов (то есть вызовов, завершаемых на мобильном терминале), запрос установки вызова всегда прибывает на ШВВ, который опрашивает ДСА, осуществляет фильтрацию входящего вызова и передает (без выполнения какой-либо функции управления вызовом) запрос к Обслуживающему серверу ФУСВ/ЦКПС. Если отправляющие сети ОИП Версии 2000 имели возможности запрашивать ДСА целевой сети, то будет возможно адресовать запрос установки вызова к обслуживающей ФУСВ непосредственно.
Что касается отправленных вызовов, то обработку запроса вызова осуществляет Обслуживающий сервер ФУСВ/ЦКПС (если существует) или домашняя ФУСВ, когда ФУСВ обслуживания отсутствует.
Настоящий раздел рассматривает только услуги КП.
9.3.2. Сценарий 1, Традиционная Модель
На последующих фигурах показан соответственно роуминг по сценарию 1, применяемому к роумингу внутри одиночной сети, и применяемому к роумингу между сетями.
Фиг.9-2: Сценарий 1, применяемый к роумингу внутри одиночной сети
Фиг.9-3: Сценарий 1, применяемый к роумингу между сетями
Сценарий 1 характеризован следующими пунктами (точками):
как Домашняя ФУСВ, так и ФУСВ обслуживания существуют и активны;
вызовы ПТ маршрутизируют к ФУСВ обслуживания через Домашнюю ФУСВ;
не основные услуги (например, вспомогательные услуги и т.п.), инициируемые вызовами ОПА и требующие взаимодействия с логикой услуги, конкретной для оператора домашней сети, могут быть обеспечены двумя способами:
ФУСВ обслуживания имеет прямой интерфейс к логике услуги (например, прямой интерфейс к ПУО в случае ИС), вариант (1) на указанных выше фигурах;
только Домашняя ФУСВ имеет доступ к логике услуги и две ФУСВ действуют совместно для того, чтобы обеспечить услугу, вариант (2) на указанных выше фигурах;
вызовы ПТ, которые достигают ФУСВ обслуживания, обрабатывают посредством ФУСВ обслуживания для базовых речевых услуг;
вызовы ПТ, инициирующие не основные услуги, обрабатывают, как описано для вызовов ОПА;
пользовательский уровень для вызовов ПТ маршрутизируют от отправляющей сети к обслуживающей сети через домашнюю сеть (т.е. от КТСОН к МШ и к УПМУ в обслуживающей сети);
пользовательский уровень для вызовов ОПА к сетям ОИП не по Версии 2000 (и для сетей ОИП не оптимизированной Версии 2000 к вызовам сетей ОИП Версии 2000) маршрутизируют от обслуживающей сети к КТСОН через МШ в обслуживающей сети, таким образом оптимизируя маршрутизацию на пользовательском уровне. В случае роуминга внутри той же сети, МШ может быть снова выбран как близкий для сети каналов-носителей, чтобы оптимизировать маршрутизацию на пользовательском уровне;
Домашняя ФУСВ реализует переключения фильтров (т.е. переключений для вспомогательных услуг и услуг ИС для входящих вызовов) входящих вызовов и передает сигнализацию управления вызовом по адресу ФУСВ обслуживания, извлеченному в течение опроса ДСА.
9.3.3. Сценарий 2
На последующих фигурах показан соответственно роуминг по сценарию 2, применяемому к роумингу внутри одиночной сети и применяемому к роумингу между сетями.
Фиг.9-4: Сценарий 2, применяемый к роумингу внутри одиночной сети
Фиг.9-5: Сценарий 2, применяемый к роумингу между сетями
Сценарий 2 характеризован следующими пунктами:
присутствует только CSGF обслуживания;
вызовы ПТ маршрутизируют к ФУСВ обслуживания через ШВВ в Домашнем домене/сети;
все услуги (основные и не основные), инициированные в течение вызовов ПТ и ОПА, обеспечены ФУСВ обслуживающей;
если "не основные" средства услуг не стандартизованы, то такие услуги будут вовлекать ФУСВ обслуживания и элементы внутри Домашнего домена и домена логики услуг;
пользовательский уровень для вызовов ПТ маршрутизируют от отправляющей сети к обслуживающей сети через домашнюю сеть (т.е. от КТСОН к МШ, к УПМУ в обслуживающей сети);
пользовательский уровень для вызовов ОПА к сетям ОИП Версии 2000 (и для вызовов от сетей ОИП не оптимизированной Версии 2000 к сетям ОИП Версии 2000) маршрутизируют от обслуживающей сети к КТСОН через МШ в обслуживающей сети, оптимизируя таким образом маршрутизацию на пользовательском уровне. В случае роуминга внутри сети МШ может быть повторно выбран "close" для сети каналов-носителей, чтобы оптимизировать маршрутизацию на пользовательском уровне.
9.3.4. Сценарий 1: Потоки информации для проверки правильности
Для того чтобы проверить правильность сценария 1, предложенного выше, в настоящем разделе приведены потоки информации для регистрации, управления положением и вызова доставки/отправления.
Потоки информации, представленные в предложениях по Управлению вызовом и Роумингу, не обеспечивают многих подробностей. Для сообщений сигнализации были выбраны общие имена. Любое сходство с известными существующими протоколами является следствием попытки сделать предложения по потокам информации немедленно узнаваемыми. Только ограниченное подмножество возможных потоков информации включено в настоящий документ.
9.3.4.1. Регистрация и управление положением
В настоящей версии Технического отчета рассмотрена только основная (базовая) процедура регистрации.
основная (базовая) процедура регистрации составлена из трех этапов:
подсоединение УОНПР: является открытой (простой) процедурой подсоединения УОНПР;
активизация контекста PDF: контекст PDF устанавливают для поддержки сигнализации на уровне приложения;
регистрация на уровне приложения с ФУСВ.
Последнее рассмотрено в потоках регистрации, приведенных ниже.
Показаны два основных варианта регистрации, чтобы представить начальную картину регистрации на прикладном уровне.
Фиг.9-6: Осуществление регистрации пользователя сети ОИП Версии 2000 в обслуживающем домене сети ОИП Версии 2000
Этапы 4 и 5 являются необязательными и их осуществляют только в двух случаях:
если пользователь был прежде зарегистрирован в другой ФУСВ обслуживания;
если пользователь не был прежде зарегистрирован, но в течение вызова ПТ, ДСА определил, что профиль услуги был необходим в Домашней ФУСВ для обработки вспомогательных услуг, запускаемых входящим вызовом (например, пересылаемый вызов мультимедиа, запускаемый вызовом ПТ).
Другие сценарии регистрации и управления положением являются ДДИ.
9.3.4.2. Вызовы ПТ/ОПА
Два потока информации вызовов представлены в настоящей версии Технического отчета. Потоки для вызовов основаны на следующей модели доставки вызова:
вызов от КТСОН к СН, соответствующий пользователю, принимают одной из ФУМШ Домашней Сети, ПУИ или домена корпоративной ЛВС в сети IP мультимедиа;
ФУМШ достигает Домашней ФУСВ, преобразующей СН;
Домашняя ФУСВ опрашивает ДСА, чтобы извлечь информацию относительно пользователя, соответствующего СН;
Домашняя ФУСВ принимает информацию о том, как вызов должен быть маршрутизирован: в потоках, показанных в настоящем документе, ДСА возвращает адрес сигнализации ФУСВ обслуживания, но в общем случае может быть транспортным адресом ПС, если нет ФУСВ обслуживания или номера, к которому осуществляют пересылку. ДСА также может вернуть информацию профиля услуги в том случае, когда пользователь не зарегистрирован.
Домашняя ФУСВ пересылает сигнализацию вызова по запрошенному адресу.
Что касается пользовательского уровня, то пакеты маршрутизируют от МШ МШ домена корпоративной ЛВС или домашней сети к УПМУ в сети каналов-носителей, в которой пользователь расположен в текущее время.
Оптимизация не была рассмотрена для пользовательского уровня вызова МО. Для тех случаев, когда желательна оптимизация маршрутизации МО, с применением различных возможных критериев может быть выбрана ФУМШ, используемая для маршрутизации вызова к КТСОП.
9.3.4.2.1. Входящий вызов от КТСОП к сети ОИП Версии 2000
Следующим ниже примером потока описана доставка вызова, предназначенного для вызова ПТ, от КТСОП к пользователю сети ОИП Версии 2000, адресуемому посредством СН.
Фиг.9-7: Входящий вызов от КТСОП к сети ОИП Версии 2000
Такие вопросы, как согласование КО, управление политикой и т.д., являются ДДИ.
9.3.4.2.2. Вызов от сети ОИП ПП3П/сети IP мультимедиа к сети IP ПП3П
В следующем ниже примере потока сделано предположение, что пользователь сети ОИП Версии 2000 вошел в визитную сеть. Пример потока описывает вызов от другой сети ОИП Версии 2000, который завершается в домашнем домене вызываемого пользователя. Сделано предположение, что сети ОИП Версии 2000, из которой приходит вызов, известна информация о плане адресации (адресация на основании IP), которая позволяет завершать вызов непосредственно в ФУСВ-Д (иначе вызов мог быть маршрутизирован через КТСОП и завершен в ФУМШ).
Необходимо работать над подробностями (прохождения вызова).
Фиг.9-8: Вызов от сети ОИП Версии 2000 к сети ОИП Версии 2000
9.3.5. Сценарий 2: Потоки информация для проверки правильности
В настоящей версии документа потоки не будут показаны.
9.4. Роуминг к другим сетям
Для того чтобы гарантировать совместимость и простой роуминг между ГСПС/УОНПР 2П, УМТС R99 и доменом КК УМТС R00 и доменом УОНПР (исключая из них домен РДИП/мультимедиа), используют одинаковые процедуры (управления) мобильностью внутри сетей 3-го поколения и между сетями 3-го поколения (сохранение текущего положения в ДСА, использование МАР, чтобы обновлять в ДСА текущее положение абонента для пользователя и загружать/обновлять данные абонента на визитном узле).
Очевидно, необходимы некоторые расширения по отношению к текущим процедурам мобильности:
в случае роуминга терминала R00 в ЦКПС/УУОН сети 2П/R99:
- Р-МСС передает все сообщения МАР/САР между ДСА/ПУО и функциями (ЦКПС, УУОН...), обрабатывающими вызов/сеанс в БС 2П/R99.
- ДСА R00 посылает к ЦКПС/УУОН преобразование МАР_R99 абонентских данных, совместимых с данными, которые может обрабатывать ЦКПС/УУОН R99. Это будет классической обработкой контекста для приложения МАР.
в случае роуминга терминала R00 в сети R99 и запросе мультимедийной услуги: как и в R99 отсутствует стандартный способ иметь визитный GK, то
- Либо для того, чтобы получить специализированную услугу, терминал R00 запрашивает услугу от своей домашней ФУСВ в своей сети R00. Р-МСС не задействована в этом случае.
- Либо используют услугу GK в визитном СОПНПО и услуга не может быть специализирована. Р-МСС не задействована в этом случае.
в случае роуминга терминала R99 в ЦКПС/УУОН сети R00:
- Р-МСС передает все сообщения МАР/САР между ОРМ/ПУО и функциями (УУОН...), обрабатывающими вызов/сеанс в БС ОИП R00. ВРМ R00 (в УУОН и/или домене КК) или функция обработки вызова/сеанса способна интерпретировать МАР_R99/САР_R99, принятые от ОРМ/ПУО R99.
в случае терминала R99, осуществляющего роуминг в сети R00 и запрашивающего мультимедийную услугу: как и в R99 отсутствует стандартный способ иметь визитный GK,
- Либо для того, чтобы получить специализированную услугу, терминал R99 запрашивает услугу от своей домашней ФУСВ в своей сети R99. ШС-Р не задействована в этом случае.
- Либо используют услугу GK в визитном СОПНПО и услуга не может быть специализирована. Р-МСС не задействована в этом случае.
На настоящее время предложены два решения для роуминга. Эти решения не находятся в полном противоречии одно другому, а фактически включают в себя достаточно много общего. Тем не менее, необходима дальнейшая работа для идентификации общих свойств объединения предложений. Оба предложения суммированы в настоящем разделе со ссылками на более подробные описания. Представленные варианты роуминга и ключевые вопросы, касающиеся содействия им, следует рассмотреть дополнительно и взять в качестве основы для дальнейшей работы по определению модели роуминга для сетей R00. Другие решения для роуминга являются предметом дальнейшего исследования.
9.4.1. Процедура роуминга для сетей R00
Одно возможное решение для поддержки роуминга в сетях R00 описано в документе Tdoc S2k99117. Документ охватывает как вопросы роуминга между сетями R00, так и роуминг в действующих сетях подвижной связи. В документе дан материал по архитектуре «только КП» в УМТС R00. Роуминг от УМТС R99 рассмотрен в этом документе в терминах роуминга USIM. В документе сделаны некоторые предположения по управлению мобильностью и идентификации сети, которые должны быть рассмотрены в качестве части будущей работы. Для возможности обсуждения роуминга введена основная процедура регистрации.
Описываемыми сценариями роуминга являются:
Роуминг внутри домена КП сетей R00;
Роуминг из домена КП сетей R00 к сетям 2П/УМТС R99;
Роуминг от сетей 2П/УМТС R99 к домену КП сетей R00.
9.4.2. Роуминг с перекрытием
Одно решение роуминга заключается во введении услуги перекрытия персонального номера, которая отслеживает пользовательские регистрации (присоединенные к 2П/3П КК и/или к КП мультимедиа) и глобальные параметры приема вызова. Это допускает как межсервисный, так и межсетевой роуминг для телефонной связи, как классической услуги дистанционной передачи речи в сетях 2П/3П, и телефонной связи, как речевого компонента мультимедийной услуги.
Предлагаемое решение вопросов роуминга дополнительно подробно описано в документе Tdoc S2K-99070. В документе Tdoc приведена разработка в деталях управляющих воздействий для роуминга с перекрытием и в состав документа включены примеры пользовательской регистрации и вариантов приема вызовов.
9.5 Открытые вопросы
Нижеследующие вопросы должны быть обсуждены и решены посредством взаимодействия с другими рабочими группами по Версии 2000 сети ОИП и могут потребовать пленарного обсуждения.
Поддержка коллективных сеансов связи для передачи речи и данных (включая в состав возможность для пользователя или логики услуги динамического добавления или удаления из активного сеанса связи). Должно быть исследовано влияние на уровень управления (например, ФУСВ) и на уровень пользователя (например, использование ФМР против группового IP).
Должны быть определены структура и функциональность СПМ. Как пример, СПМ может иметь дополнительный интерфейс (например, GRIC CSP) к прошедшим контроль домам, как определено в H.225. GRIC Communications, Inc. разрабатывает глобальную платформу интеллектуальной транзакции (GRIC CSP), которая допускает взаимодействие разнообразных сетей. Эта платформа допускает ПУИ, Телефонные Компании и новые носители, чтобы предложить множественные, основанные на IP услуги такие, как IP-телефония, электронная коммерция, роуминг в Интернете факсимильная связь в Интернете. Используя по-новому сеть Союза GRIC, всемирное членство более 450 ведущих ПУИ и телекоммуникации в более чем 140 странах, GRIC суммировал адресуемую пользовательскую базу для 30 миллионов пользовательских номеров и оцениваемую в 40 миллионов единиц корпоративных пользователей. Для получения дополнительной информации о GRIC следует обращаться к ресурсу http://www.gric.org/. Подлежит обсуждению оптимизация маршрутизации для вызовов, отправленных из сети ОИП Версии 2000 к ПС другой сети ОИП Версии 2000 и адресуемых с использованием СН, осуществляемая для того, чтобы обходить КТСОН.
Должна быть также описана маршрутизация вызовов ПТ к ЛИ. Должно быть обсуждено введение функций ФУСВ и решения должны быть представлены на следующей встрече. Влияние требований, относящихся к обратной совместимости с 20 сетями (например, СРД, терминалы, управление вызовом и роуминг, услуги), требуют рассмотрения.
Вопросы конфиденциальности местоположения должны быть рассмотрены по отношению к оптимизации сигнализации и транспортных маршрутов.
Сеть ОИП Версии 2000 должна обеспечивать для логики услуг возможность отвергать или переадресовывать запросы на передачу речи и/или данных. Такая возможность должна быть применена как к входящим запросам на передачу данных, так и к запросам на передачу, инициированным пользователем.
Должны быть также рассмотрены проблемы лавинной адресации (распространения пакетов) и злонамеренных атак на сеть.
Вопрос возможного воздействия на архитектуру с точки зрения того, где в ней должно быть реализовано большее количество функций брандмауэра.
Адресация множественного потока PDP посредством одного IP адреса должна быть решена как передача, если еще не нормализовано для УОНПР.
Подлежат исследованию подробности, касающиеся множества вокодеров, поддерживаемых в сети ОИП Версии 2000, и способ и средства согласования вокодеров.
Поток PDP сигнализации может быть активизирован, когда ПС подсоединяют/регистрируют в сети и сохраняют действующей в течение всего сеанса присоединения/регистрации (неактивный поток PDP сигнализации), или она может быть активизирована по требованию. Выбор между двумя опциями следует обсудить, принимая во внимание вопросы персонального вызова, загрузки, обусловленной ММ для неактивного контекста PDP даже, в том случае, когда ПС находится в состояния простоя, и влияние на ПС.
Рассматривают ли T.I 20 как приложение реального времени, то есть должны ли компоненты T.I 20 для вызовов мультимедиа быть управляемыми посредством ФУСВ?
Запросы к базе данных в ДСА и к другим сетевым базам данных подлежат обсуждению и определению.
Должна быть определена адресация сетевых элементов и преобразование адресов (например, предполагают, что ФУМШ имеет возможность извлекать сервер ФУСВ/ЦКПС, соответствующий СН; как ФУМШ осуществляет это - ДДИ).
Должно быть обсуждено хранение профилей 2П в сети ОИП Версии 2000 с целью поддержки роуминга в действующих сетях 2П. В частности, наличие и функциональность ОРМ 2П в ДСА должны быть обсуждены и оценены и возможные другие варианты.
Должны быть рассмотрены перспективные вопросы и предположения, то есть не относящиеся только к R00, для того, чтобы иметь решение с проверкой будущим. Как пример, подлежат рассмотрению перспективные требования к способам адресации (например, динамическим против статических, IPv4 против IPv6).
Должен быть определен тип функциональности "ВРМ", который предусматривает для пользователя возможность кэширования профиля услуги в обслуживающем домене. Такая функциональность не должна быть связана с управлением положением, быть сфокусированной на профиле услуги.
Различия в определении термина "Положение", как оно понимаемо в пределах сообщества сотовой/беспроводной связи и в обществе КИПСИ, еще не были рассмотрены в настоящем документе. Это должно быть согласовано.
Должна быть рассмотрена поставка услуг, основанных на местоположении (например, услуга на основании информации о географическом положении), и влияние на архитектуру.
Вопросы КО и безопасности еще не были рассмотрены.
10. Влияние платформы (реализации) услуг
10.1. Архитектура услуг ПП3П по Версии 2000
В настоящем разделе описано, как архитектура [3] услуг ПП3П по версии 99 может быть применена к сети ПП3П версии 2000 путем расширения концепции ВДС/АОУ до (концепции) базовой сети мультимедиа. Это может быть сделано посредством обеспечения прикладного интерфейса (как описано в спецификации [3] ВДС) от ФУСВ, см. Фиг. 10-1. Поскольку ВДС ожидает услугу, которая должна быть расположена в домашнем домене конечного пользователя (Домашняя Среда), другие сетевые элементы, кроме ФУСВ, могут быть необходимы для обеспечения архитектуры роуминга, которая позволяет обслуживающему домену передавать управление домашнему домену, в котором находится логика услуги (в текущих спецификациях ПП3П это достигают через СПРЛПС, обеспечивающей интерфейс САР между обслуживающей и домашней сетями).
* Примечание: архитектура, приведенная на Фиг.10-1, и среда (СУС) услуг СПРЛПС, приведенная на Фиг. 10-2, не показаны в Эталонной Архитектуре в Разделе 5.
Фиг.10-1: Архитектура услуг ПП3П Версии 2000
Открытая Архитектура Услуг состоит из трех частей, как проиллюстрировано на Фиг.10-1 (отметим, что иллюстрация не означает, что фигура является полной в отражении всех взаимозависимостей):
Приложения, например, ВЧС, конференции, основанные на местоположении приложения. Эти приложения реализованы одним или более серверами приложений;
Инфраструктура, обеспечивающая приложения основными услугами, которые позволяют приложениям использовать возможности услуг в сети. Примерами услуг инфраструктуры являются аутентификация, регистрация и обнаружение;
Возможности услуг, обеспечивающие приложения услугами, которые являются абстракциями базовой функциональности сети. Примерами услуг, предлагаемых возможностями услуг, являются Управление вызовом, Передача сообщений и Местоположение. Услуги возможно предоставляют более чем одним сервером возможностей услуг. Например, услуга Управления вызовом может быть предоставлена посредством СПРЛПС и ИСПС. Серверами возможностей услуг, которые принимались в рассмотрение для УМТС 99 Версии, являются СПРЛПС, MExE, СПИС и ОРМ.
Фиг.10-2: Обзор архитектуры открытых услуг
10.2. Услуги на основании ИС
Услуги на основании ИС являются примером действующих услуг и логика основанных на ИС услуг является примером того, как действующие услуги могут быть введены в сети ПП3П Версии 2000. Логика основанных на ИС услугах может нуждаться в расширениях для сетей ПП3П Версии 2000, основанных на предлагаемой архитектуре в том случае, когда потребуется полная поддержка мультимедиа.
Когда должны быть поддержаны только речь/аудио, то существуют различные варианты выбора:
1. Переадресация вызова к действующим системам. Это применимо к весьма конкретным услугам таким, как услуги 800 и 900.
2. Обеспечение интерфейсов, подобных ППИС, между функциональными блоками (например, ФУСВ) сети ПП3П Версии 2000 и действующей ПУО. Эти интерфейсы будут использованы для интер- и инфрасетевых соединений и как таковые должны быть основаны на соответствующем протоколе ППИС (например, САР).
3. Обеспечение новых интерфейсов между действующей ИС и функциями сети ПП3П Версии 2000, допускающей для СП возможность иметь доступ к приложению в действующей ПУО.
Следует отметить, что специализированные услуги оператора связи, определенные для сетей УОНПР, допускающих КО, по-прежнему доступны и применимы для доступа каналов-носителей к базовой сети ММ. Это будет для экземпляров, разрешающим получать предварительную оплату канала-носителя УОНПР.
Как указано в разделах ниже, вариант 2 (раздел 10.2.1) будет допускать возможность, что существующие услуги могут быть обновлены для обеспечения пользователей 3П «бесшовным» переходом известных услуг 2П, особенно при роуминге. Вариант 3 (раздел 10.2.2) не обладает таким преимуществом, но имеет преимущества от проверки будущим. Таким образом, кажется разумным допустить сосуществование таких двух вариантов, при которых поддержка действующих услуг СПРЛПС была бы переносима посредством варианта 2 и расширенные/будущие услуги могли бы быть обеспечены посредством принципов АОУ, как это определено в варианте 3 или комбинацией обоих вариантов.
10.2.1. Интерфейс между действующей ПУО и сетевыми элементами на основании ППИС.
В этой опции классическая модель ИС расширена, чтобы включить ФУСВ в качестве узла, способного поддержать функцию переключения услуг (основанную на спецификации 23.078 gsmSSF) и протокол, основанный на транзакции (TCAP) с САР. Концептуально новая функциональная составляющая введена между ФУСВ и СУС. Эта функциональная составляющая, названная softSSF, может быть потенциально основана на модифицированной для версии 99 функциональности ШЦКПС, ВЦКПС (VMSC, Виртуальный ЦКПС) и ВРМ, в которых оставлены или расширены функции управления вызовом, учета и баз данных. Такая softSSF взаимодействует с СУС через САР и взаимодействует с ФУСВ либо через внутренний интерфейс (если он размещен совместно с ФУСВ), либо через открытый интерфейс на основании принципов АОУ (если softSSF развернута как сервер возможностей услуг). Можно ожидать некоторых изменений в САР, чтобы принять во внимание влияние нижележащего управления IP вызовом. СУС может предлагать свои услуги через определенный открытый интерфейс, основанный на принципах Архитектуры открытых систем. Такие услуги могут быть осуществлены посредством СУС через интерфейсы САР к УУОН и ФУСВ. (Отметим, что ФУСВ может также предлагать свои услуги через определенный открытый интерфейс, основанный на принципах АОУ).
Преимущества такой опции заключаются в расширенном повторном использовании стандартизованного процесса (gsmSSF), протокола (САР) и уже развернутых услуг.
Фиг.10-2: функциональная архитектура для варианта 2 поддержки
10.2.1.1. Преимущества
Максимизирует повторное использование существующих функциональных составляющих, протоколов и услуг. Такое повторное использование уменьшает издержки на разработку и (монопольное) использование, допуская для существующих известных услуг 2П возможность предоставления их пользователям 3П на ранней стадии.
Минимизация изменений в СУС для поддержки действующих услуг. Существуют несколько уже развернутых услуг ИС/СПРЛПС: Предоплата, ВЧС, Переносимость мобильного номера и т.п., которые могут быть использованы в передаче речевых данных по IP-сети.
Потенциально САР/TCAP может быть носителем в IP (это требует дальнейших исследований/материалов (документов)).
Настоящий метод находится в соответствии с работой, осуществляемой в настоящее время в ЕИСОТ (ETSI) SPAN 3 (Услуги и Протоколы), в частности в пункте работы, обращающемся к поддержке ИСдля передачи речи по IP в архитектуре H.323 и соответствующих протоколах, связанных с проектом TIPHON. Исследование будет осуществлять анализ того, как контроллер зоны, соответствующий H.323, может действовать в качестве виртуального Пункта коммутации услуг (ПКУ, SSP). Это имеет смысл имея в виду, что план ETSI согласовать протокол ИС для фиксированных линий (Ядро ETSI INAP CS3.1) и мобильный эквивалент (Фаза 3 САР) в общий протокол, предназначенный для ядра ETSI INAP CS4.
10.2.1.2. Недостатки
Введение новой функциональной составляющей «softSSF», которая обеспечивает необходимое отображение между ФУСВ и СУС. Однако такая функциональная составляющая основана на функциях, уже обеспечиваемых ВЦКПС/ШЦКПС, в которых может быть повторно использован уже стандартизованный процесс, как, например, gsmSSF. Интерфейс между ФУСВ и softSSF требует дальнейшего исследования.
10.2.2. Новый открытый интерфейс между действующими ПУО и сетевыми элементами R00
Эта опция принимает принципы АОУ, в которой Серверы возможностей услуг (СВУ) таких, как ФУСВ и действующая ФУУ, определили ИПП (API), который допускают для приложений в отдельных серверах приложений использование свойств, предлагаемых этими СВУ. Такой подход допускает то, что свойства услуг, обеспечиваемые посредством СВУ, могут быть сделаны доступными для разработчиков приложений с имеющимся подробным знанием конкретных протоколов. В текущее время СВУ отражают возможности услуг в фазе 1 УМТС, и СПРЛПС служит в качестве одного из примеров. Из документа TS 22.121 - «сервер возможностей услуг состоит из одного или нескольких компонентов сервера. Взяв услуги СПРЛПС в качестве примера, компонентами сервера могут быть Управление вызовом, Положение/Позиционирование, Информация и уведомления СОПНПО. Каждый из компонентов сервера предлагает услуги через определенные открытые интерфейсы и реализует их, используя протоколы GSM/УМТС.»
Проблема в том, что внутри сети ОИП упомянутые выше компоненты сервера не все доступны через СУС, поскольку нет нижележащего (базового) протокола между СУС и сетью, предназначенного для управления вызовом (отдельно от интерфейса СУС/УУОН). Для обеспечения такой же функциональности, которую обеспечивают существующие действующие услуги, должны быть созданы новые приложения, которые осуществляют некоторое ограниченное использование свойств, которые может предлагать СУС (например, поиск в базе данных), и плюс свойства услуг, предлагаемых в ФУСВ.
Будут присутствовать API, поддерживающие модели клиент-сервер. Такие API дадут возможность пользователю иметь доступ к логике услуг через ПО и серверы специалиста (например, ИСПС). Интерфейс такого сервера специалиста и ФУСВ являются предметом для дальнейшего исследования.
Фиг.10-3: функциональная архитектура для варианта 3
10.2.2.1. Преимущества
Открытый интерфейс на основании концепций АОУ. Ожидают, что интерфейсы API, которые могут взаимодействовать с ФУСВ и СУС, будут доступными, позволяя конкретным протоколам быть скрытыми от разработчиков услуг/приложений.
Более легкое развертывание новых/расширенных услуг для мультимедийных приложений.
10.2.2.2. Недостатки
При рассмотрении существующих базовых услуг СУС делают небольшое повторное использование уже стандартизованных протоколов, услуг и процессов. Новые процессы и протоколы должны быть переопределены и повторно осуществлены для услуг, которые уже существует, что повышает издержки на разработку и использование.
Требует создания новых приложений на сервере приложений для того, чтобы поддержать действующие услуги. Считают, что влияние на действующие СУС и услуги будет большим, чем в варианте 2.
10.3. Вопросы для дополнительной проработки
Следующие вопросы требуют дополнительной проработки:
Приложения могут находиться не только на серверах приложений (СП), но также на терминалах.
Варианты для разделения приложений или их частей между СП и терминалами.
Какие элементы, кроме ФУСВ, будут обеспечивать API для разработки приложения (согласованный с ВДС/АОУ).
Терминал должен также обеспечивать API для разработки приложения (согласованный с MExE).
Какие новые Возможности услуг/Свойства возможностей услуг необходимы для Версии 2000 ПП3П (например, БИС).
Должны быть обеспечены конкретные варианты осуществления предлагаемой архитектуры.
Если, то как свойства услуг Версии 2000 ПП3П могут быть сделаны доступными для 2П терминалов через сети 2П.
Если, то как свойства услуг Версии 2000 ПП3П могут быть сделаны доступными для дуального режима 2П/3П терминалов через сети 2П.
11. Безопасность
Будет общая схема аутентификации для терминалов, действующих в режиме ОИП, который будет основан на SIM/USIM. Требуется, чтобы терминалы ОИП могли регистрировать и обеспечивать основную услугу при использовании с SIM/USIM ПП3П.
12. План работ
12.1. Промежуточные сроки для Версии 00
ПП3П ставит целью создание второй версии описания УМТС к окончанию 2000. Управление проектом для этой работы потребует включения в его состав элементов определения пакета работ, взаимозависимости таких пакетов работ и их планирования. Поскольку в ПП3П работу предпринимают в формах различных TSG (ГТУ) и WG (РГ), то будет необходимо соглашение между такими группами по общему плану. Последующее взаимодействие между такими группами по таким вопросам, как изменения в планы и требования, будет существенным. Дополнительной задачей, имеющей отношение к взаимодействию, является обзор документов требований с целью определения технических проблем в осуществлении (работ) на ранней стадии. Завершение версии 99 обладает потенциалом воздействия на доступность ресурсов и, следовательно, масштабирования временных сроков для версии 00. Отметим: "текст, который следует далее является более общим по сути, чем остальная часть документа. Он был включен, чтобы показать инфраструктуру для версии 2000, в которой Архитектура ОИП может быть одним из пунктов работы. Показанные даты являются принятыми датами и подлежат проверке посредством TSG-S2."
12.1.1. Промежуточные сроки версии 00
ПП3П еще не согласовала общие промежуточные сроки для версии 00. Для целей разработки высокоуровневого плана работы предложены следующие ключевые промежуточные сроки.
Июль 99 Начало разработки технико-экономического обоснования сети ОИП ПП3П
Сент 99 Специальная TSG-S2 R00 предъявит на рассмотрение результаты TSG-S2 для утверждения
Окт 99 После утверждения TSG-S2 результаты Специальной группы TSG-S2 R00 будут предъявлены на рассмотрение TSG-S для утверждения
Окт 99 После утверждения Проекта группой TSG-S будет начата работа по планированию для R00 (включая в состав вариант сети ОИП) в специальных группах по планированию работ TSG-S2 (Такие группы имеют требуемое участие от всех соответствующих TSG/WG).
Дек 99 После утверждения TSG-S2 подробный план работ для R00 (включая в состав вариант сети ОИП) будет предъявлен на рассмотрение TSG-S для утверждения.
Дек 99 Наличие требований к услугам Версии 00
Янв 00 TSG-SA2 завершает первый эскизный проект архитектуры для сети ОИП.
Янв 00-Дек 00 Продолжение работы внутри TSG и WG ПП3П в соответствии с утвержденным TSG-S планом проекта R00
Дек 00 Описания версии 00 завершены, включая в состав вариант ОИП
На обратной стороне дают высокоуровневую схему МОСП (PERT) (Метод оценки и согласования проекта, МОСП), чтобы сформировать основу планирования для версий выше R99. Просмотренные первые эскизные проекты услуги и описания архитектуры должны быть доступны перед окончанием 1999.
12.1.2. Подробный план деятельности
История документа
Изобретение относится к сетевым системам, позволяющим проводить сеансы обмена информацией между большим количеством пользователей и устройств в среде с коммутацией пакетов и может быть использовано для обеспечения информации о присутствии пользователя. Подсистема телекоммуникационной сети, использующей Интернет-протокол, для среды приложений и услуг содержит сервер «присутствия» и блок, выполняющий функцию управления состоянием вызова обслуживания, адаптированный для приема сообщений регистрации, пересылаемого от пользовательского оборудования, и для дальнейшего выполнения отдельной транзакции регистрации на сервере «присутствия» для пользовательского оборудования. Технический результат - обеспечение маршрутизации сообщений регистрации. 33 з.п. ф-лы, 9 ил.
| Переносная печь для варки пищи и отопления в окопах, походных помещениях и т.п. | 1921 |
|
SU3A1 |
| US 5313653, 17.05.1994 | |||
| US 6041229 A, 21.03.2000 | |||
| US 5600704 А, 04.02.1997 | |||
| ИВАНОВА Т.И | |||
| Абонентские терминалы и компьютерная телефония | |||
| - М.: ЭКО-ТРЕНДЗ, 1999, с.129-131. | |||
