Функционально-технические требования
к развертыванию услуг
«Rich Communication Services»
Москва
2015
Оглавление
Требования по защите инвестиций 31
Требования по гарантийному и техническому обслуживанию оборудования 32
Функция документа
Настоящий документ описывает функционально-технические требования к Системе, обеспечивающей функционирование услуги Rich Communication Services (далее RCS), а также требования к поставке, пуско-наладке и интеграции оборудования в существующую сеть ОАО МГТС.
Данные требования определяют набор интерфейсов и функционала, обязательных к исполнению производителем, для признания Системы пригодным к использованию в процессе оказания услуг абонентам ОАО МГТС.
В рамках настоящего запроса информации Участник должен представить предложение по поставкам оборудования и программного-обеспечения, включая все элементы, обязательные и опциональные, а также по пуско-наладке и интеграции оборудования в существующую сеть ОАО МГТС.
Предложение должно быть представлено в виде прайс-листа с указанием спецификации и отдельно стоимости оборудования и работ по каждому объекту и суммарно.
Компания оставляет за собой право включать дополнения и изменения в технические требования, спецификации работ и сроки их исполнения при заключении договора с Участником.
Язык предложений
Язык подачи предложений Участниками процедуры запроса информации ОАО МГТС и всей сопроводительной документации по проекту -
Русский
Терминология
Наименование термина
|
Сокращение
|
Определение термина (расшифровка сокращения)
|
Основные определения:
|
Rich Communication Services
|
RCS
|
Платформа, позволяющая совершать телефонные и видео звонки, отправлять SMS, MMS, мгновенные сообщения и обмениваться файлами между различными устройствами.
|
Система
|
Система
|
Совокупность Программного обеспечения и Оборудования, обеспечивающая функционирование RCS
|
Вводимые определения:
|
Операционная Система
|
ОС
|
Комплекс программ, обеспечивающий управление аппаратными средствами компьютера, работу с файлами, ввод и вывод данных, а также выполнение прикладных задач и утилит.
|
Техническое задание
|
ТЗ
|
Исходный документ для конструирования технического устройства либо разработки информационной системы. ТЗ содержит основные технические требования, предъявляемые к изделию.
|
Multipurpose Internet Mail Extensions
|
MIME
|
Набор стандартов описывающих передачу различных типов данных посредством электронной почты и других средств.
|
Network Time Protocol
|
NTP
|
Протокол сетевого времени. Протокол, с помощью которого производится синхронизация системного времени компьютера с временем NTP-сервера.
|
Secure copy
|
SCP
|
Протокол копирования файлов, использующий в качестве транспорта протокол SSH.
|
SSH File Transfer Protocol
|
SFTP
|
Протокол, предназначенный для обмена и управления данными поверх какого-либо криптографического протокола (обычно SSH).
|
Secure Shell
|
SSH
|
Протокол, позволяющий передавать данные и производить удалённое управление операционной системой по защищенному каналу.
|
Transport Layer Security
|
TLS
|
Криптографический протокол, обеспечивающий конфиденциальность и целостность данных при их передаче по сети.
|
Мобильное приложение
|
МП
|
Приложение для работы с услугой, устанавливаемое на мобильном устройстве абонента
|
Personal computer
|
PC
|
Персональный компьютер
|
PC-клиент
|
|
Клиент, установленный на PC
|
Коммуникация
|
---
|
Совершение абонентом услуги голосового и видео-вызова, отправка SMS-сообщения или текстовые сообщения.
|
Business requirement
|
BR
|
Бизнес требование
|
Functional requirement
|
FR
|
Функциональное требование
|
Опционально
|
---
|
Требования, отсутствие которых, не может служить отказом от рассмотрения коммерческого предложения, но которые могут быть учтены на этапе выбора поставщика, при прочих равных условиях.
|
Описание технического решения
Необходимо развернуть Систему для оказания услуг
Rich Communication Services (RCS 5.1) и интегрировать ее в существующую IMS-платформу Huawei.
В рамках проекта предполагается использовать существующий TAS (Telephony Application Server) компании Huawei. Система должна иметь возможность интеграции с RCS-клиентом (мобильная и PC-версии) на базе стандарта RCS Crane компании Summit-tech. Участник вправе предложить своего RCS-клиента, если он соответствует требованиям RFI.
Система должна позволять осуществлять коммуникации с любыми номерами (мобильная связь, фиксированная связь, внутренние и международные звонки) через МП, PC-клиент или Web-приложение, с возможностью тарификации коммуникаций по тарифам, действующим на тарифном плане абонента. Под коммуникацией понимаются: голосовые и видео вызовы, SMS и MMS сообщения, мгновенные текстовые сообщения и передача файлов. В качестве идентификатора используется фиксированный номер абонента МГТС, поэтому должна быть обеспечена интеграция с лицевым счетом абонента МГТС. Коммуникация может осуществляется по каналам передачи данных (Wi-Fi, GPRS, UMTS, LTE).
При работе Системы должна использоваться абонентская база, хранящаяся на HSS, все услуги должны тарифицироваться с привязкой к абонентскому счёту, который закреплён за домохозяйством. Система не должна являться отдельной коммутационной платформой, а должна выполнять функции AS IMS.
Система должна поддерживать работу и быть проинтегрирована с основным и резервным ядром IMS.
Должна быть предусмотрена возможность ограничения услуг в зависимости от способа подключения МП или PC-клиента (IP адрес, MAC адрес, dhcp opt.82). Предполагается ограничивать клиенту возможность использования услуги зоной домашней точки Wi-Fi.
Общие требования к Участнику.
Участник должен быть официальным дилером, либо производителем Системы, предлагаемой к поставке. Документооборот Участника должен соответствовать действующему законодательству РФ. При исполнении обязательств по договору с Заказчиком не допускается смена юридического лица компании и переуступка обязательств по договорам третьим лицам. Участник обязан иметь центр сервисного обслуживания товара на территории РФ или договор об оказании услуг по гарантийному и послегарантийному обслуживанию Системы с уполномоченным сервисным центром, квалифицированный менеджмент, выделение сотрудника для работы с Заказчиком. Участник должен гарантировать готовность к оперативному реагированию в процессе переговоров, к конструктивному диалогу с Заказчиком.
Потребительские свойства продукта
Общие требования
-
Прогноз по количеству абонентов в течение 12 месяцев – не более 50 тыс. абонентов. Планируется, что в течение трех лет количество абонентов составит не более 300 тыс. абонентов.
Одна лицензия должна позволять пользоваться сервисами услуги абоненту одновременно на МП, PC и на web-интерфейсе.
Необходимо предоставить предложение для следующего количества пользовательских лицензий: 10 тыс., 50 тыс., 100 тыс. и 300 тыс. абонентов.
Реализация Rich Communication Services (RCS 5.1).
Язык интерфейса русский/английский.
Автоматическое определение возможности общения через сервис с выбранным абонентом (capability discovery) (если не будет реализован Presence).
Возможность воспользоваться сервисом абонентам любого тарифного плана.
Единый лицевой счет абонента.
Поддерживаемые режимы работы RCS-клиента
|
Возможности терминала
|
Используемый доступ
|
Предоставляемая услуга телефонии
|
Доступность и статус режима «максимально доступного качества» для Голоса/Видео
|
Режим устройства
|
Под-держка
|
|
Best Effort IP Voice & Video Call
|
LTE
|
Максимально доступное качество Голосового и Видео IP-Вызова
|
Доступно
|
RCS-AA
|
|
|
HSPA
|
Максимально доступное качество Голосового и Видео IP-Вызова
|
Доступно
|
RCS-AA
|
|
|
3G/2G
|
Максимально доступное качество Голосового и Видео IP-Вызова
|
Доступно
|
RCS-AA
|
|
|
Доступ не в режиме 3GPP/3GPP2
|
Максимально доступное качество Голосового и Видео IP-Вызова
|
Доступно
|
RCS-AA
|
|
Таблица 1: Поддерживаемые режимы работы RCS-клиента
Автоконфигурация RCS клиента
RCS приложение должно поддерживать автоконфигурацию согласно RCS 5.1, RCS-e 1.2.2 и выше.
Поставщик должен предоставить все диаграммы protocol flow для автоконфигурирования.
Должна поддерживаться автоконфигурация RCS-клиента через WLAN и другие виды bearer. Поставщик должен перечислить все поддерживаемые виды bearer и связанные ограничения при их использовании.
Если автоконфигурация RCS-приложения закончилась неуспешно по причине отказа bearer, то приложение должно поддерживать повторную попытку.
Звонки
Возможность принимать входящие вызовы с любых номеров и совершать исходящие вызовы на любые номера.
Абонент должен иметь возможность определять место приема вызова: PC, web или телефон.
АОН.
Возможность переключать вызов с PC на абонентский терминал и обратно (например, вызов может одновременно приходить на PC или МП, а абонент сам решает, как на него ответить, одновременный ответ с двух устройств запрещен).
Ожидание/удержание вызова.
RCS-клиент должен поддерживать следующие кодеки: 16 kHzHD audio, G.722, iLBC, OPUS (RFC 6716), G.729, G.711.
RCS-клиент должен поддерживать Emergency call. Поставщик должен описать связанные protocol flows.
Видео звонки
Возможность совершения видео вызовов, а также возможность перехода в режим видео вызова во время разговора.
Возможность предоставления функции video sharing, a также демонстрации ранее записанных видеороликов во время разговора.
RCS-клиент должен поддерживать следующие видео кодеки: H.263-1998, H.263-2000, H-264, WebM, H.265.
Качество связи
Приложение должно самостоятельно определять технические параметры передачи данных на основании автоматического мониторинга каналов связи. Если качество канала связи недостаточно для передачи голоса, видео должно появиться предупреждение о том, что качество канала связи недостаточно для полноценной работы сервиса.
RCS-клиент должен поддерживать in-band операции upgrade и downgrade качества голоса и переключения кодеков. Поставщик должен описать связанные protocol flow.
Instant messaging / Мгновенная передача сообщений
Чат 1&1.
Групповой чат до 20 участников.
Получение отчётов о доставке сообщений.
Информирование о том, что вторая сторона печатает.
Сигнализация о приходе нового сообщения.
RCS-клиент должен поддерживать единый IMчат для SMS, MMS, RCS для частного контакта.
File Sharing / Передача файлов
Обмен файлами любого формата.
Передача файлов между абонентами с возможностью контроля процесса передачи с обеих сторон, а также независимо от статуса принимающей стороны.
Возможность отправка карточки контакта другому контакту (vCard).
Журнал обмена и передачи файлов.
Просмотр загруженных файлов.
Возможность отправки фотографий, как сделанных ранее, так и сделанных специально для отправки.
Прием файлов возможен только в случае подтверждения принимающей стороны, возможно добавление отправителя в списки: “Никогда не принимать”, “Всегда принимать”.
