Гельгор А.Л. Технология LTE мобильной передачи данных (2011) (1151873), страница 8

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 8)

В режиме группового вещания существует возможность селективной доставки услуг в отдельныесоты (не обязательно смежные), входящих упорядоченным образом всоответствующую вещательную группу, на основании предварительной подписки. Режим обычного вещания не предполагает каких-либо53определённых требований, связанных с подпиской или активациейуслуг.В отличие от услуг сотового вещания (CBS, Cell, Broadcast Service), связанных с низкоскоростной передачей информации, мультимедийное вещание изначально ориентировано на передачу данных свысокой скоростью как в потоковом режиме, так и в режиме прерывистых сеансов связи.Также, как и для передачи обычных (невещательных) мультимедийных сообщений источником услуг мультимедийного вещания могут быть как обычные внешние интернет-серверы, так и специализированные серверы, входящие в структуру данной или соседних сетей.Для доставки сетевым пользователям вещательного контента, а такженеобходимой служебной информации организован ряд логическихинтерфейсов.Доставка мультимедийной вещательной услуги осуществляетсяна основе соответствующего MBMS-контекста, формируемого впользовательском терминале, обслуживающем шлюзе и центре вещательных услуг.

В качестве примера в табл. 1.1 представлен набор наиболее важных параметров и их описание для пользовательской частиMBMS-контекста.Таблица 1.1Параметры пользовательской части MBMS-контекстаПараметрОписаниеIP-адрес группового вещания, идентифицирующийIP multicast addressканал услуги, в котором будут объединены ПТИмя точки доступа, на которое указывает IP-адресAPNгруппового вещанияIP-адрес обслуживающего шлюзаSGW adressВременный идентификатор мобильной группы, асTMGIсоциированной с каналом услугиИдентификатор точки доступа PDP-контекстаLinked NSAPI54IMSITIMBMS_NSAPIAdditional MBMSTrace InfoTrace ReferenceTrace TypeTrigger IdОкончание табл.

1.1Международный идентификатор мобильного абонентаИдентификатор транзакцииИдентификатор точки доступа к услуге на сетевомуровнеДополнительная информация, требуемая для установки соединенияОпределяет запись или набор записей для конкретного соединенияОпределяет тип соединенияОпределяет сетевой блок, который инициирует соединениеДля обмена информацией между центром вещательных услуг иMBMS-шлюзом (рис. 1.21) определёны SGmb-интерфейс 1 (обменслужебной информацией) и SGi-mb-интерфейс (доставка пользовательской информации).

Обмен служебной информацией между БУМи MBMS-шлюзом осуществляется через Sm-интерфейс; междуMBMS-шлюзом и обслуживающим шлюзом — через Sn-интерфейс.Рис. 1.21. Архитектура сети LTE с возможностьюмультимедийного вещанияСимволы mb в названии интерфейсов подчёркивают его принадлежностьк организации услуг мультимедийного вещания.155В зависимости от использования и способа доставки услугимультимедийного вещания они классифицируются на четыре типа. Потоковые услуги (streaming service), представляющие собойнепрерывный поток данных, являются базовыми услугами мультимедийного вещания. Услуги по загрузке файлов. Карусельные (carousel) услуги, являющиеся комбинацией частипотоковых услуг (текст и неподвижные изображения) и услуг по загрузке файлов. Телевизионные услуги, состоящие из синхронизированных потоков звука и изображения.Пользование вещательной услуги в режиме группового вещаниясвязано с последовательным осуществлением следующих процедур: подписка на услугу; объявление о существовании услуги; присоединение абонента к услуге; начало передачи услуги; уведомление абонентов о начале передачи услуги; передача данных, относящихся к услуге; отключение от услуги.В сетях LTE, что является отличительной чертой систем мобильной связи 3-го и 4-го поколений, возможна либо односотовая (информация передаётся в пределах одной соты), либо многосотовая (информация передаётся в пределах нескольких сот) передача вещательных мультимедийных услуг.

При односотовой передаче данные —индивидуальный трафик — передаются по транспортному нисходящему совместному каналу DL-SCH, на который отображаются логические каналы MTCH и MCCH, и порядок следования пакетов данныхопределяется базовой станцией. ПТ могут быть назначены выделенные каналы в восходящем направлении для обратной связи в видеобычных ARQ или гибридных HARQ запросов на повторение, причём56передача с HARQ производится с использованием группового (связанного с определённой услугой) временного идентификатора RNTI(Radio Network Temporary Identifier), скоординировано во времени поотношению к передаче по каналу MTCH.Многосотовая передача выделенной услуги группового мультимедийного вещания реализуется посредством одновременной передачи идентичных радиосигналов на территории нескольких сот. В этомслучае логические каналы MTCH и MCCH отображаются на транспортный канал MCH, обеспечивая передачу информации типа “точка — много точек”.

Такой режим передачи принято называть одночастотной групповой вещательной сетью MBSFN (Multicast Broadcast Single Frequency Network).1.4.5.ПОТОКОВОЕ ВИДЕОПри предоставлении услуги потокового видео, например, какчасти услуги мультимедийного вещания, соответствующий сервер устанавливает связь с мобильным пользователем, передавая информацию с той скоростью, которая необходима для непрерывного воспроизведения видео в декодере. Такая скорость определяется различными факторами: алгоритмами видеосжатия, цветовой глубиной (т. е.числом воспроизводимых цветов), размером экрана ПТ, разрешением,временем задержки и др.

При этом результат должен быть воспроизведён на экране с задержкой, не более 1 с.Для обеспечения передачи потоковое видео в сетях 3-го и 4-гопоколений комиссия IETF 1 разработала ряд соответствующих протоколов: протокол передачи потокового видео в реальном времениRTSP (Real-Time Streaming Protocol), транспортный протокол передачи в реальном времени RTP (Real-Time Transport Protocol), протокол описания сеанса SDP (Session Description Protocol). Взаимодейст-IETF (Internet Engineering Task Force) – рабочая группа по решению проблем интернета.157вие этих протоколов в целях организации услуг потокового видеопредставлено в спецификации TS 26.234.Протокол RTSP является клиент-серверным приложением, который на транспортном уровне использует протокол TCP.

Он, как этоследует из его названия, применяется для управления доставкой потока данных в режиме реального времени, позволяя организовать несколько потоков данных с определёнными характеристиками. С помощью протокола RTSP осуществляется передача управляющих команд (воспроизведение, пауза и т. п.), но не видеоданных, которыепередаются с помощью протокола RTP, функционирующего поверхпротокола UDP.Протокол SDP описывает набор параметров различных потоковданных, включая скорость передачи кодированных данных и номерапортов1, используемых для соответствующих потоков, которые могутбыть идентифицированы при помощи RTSP-адреса, например, приуказании на медиасервер.На рис. 1.22 показана организация передачи потокового видеомежду ПТ и внешним видеосервером.Перед началом передачи услуги необходимо активизация первичного PDP-контекста, что имеет место, например, если абонент находится в состоянии постоянной готовности (always on).

При активизированном первичном PDP-контексте между ПТ и видеосервером наоснове протокола RTSP устанавливается сеанс обмена служебной информацией.Портом называется любое приложение, размещённое в каком-либо, например, оконечном узле, что позволяет адресовать запросы к определённымфайловым структурам, а также к аппаратным средствам, объединённым в однугруппу единым адресом.158ПТGGSNRTSP-серверПервичная активация PDP-контекста[RTSP] DESCRIBE[RTSP] 200 OK (SDP)[RTSP] SETUP[RTSP] 200 OKВторичная активация PDP-контекста[RTSP] PLAY[RTSP] 200 OKВидеопоток (RTP)Рис.

1.22. Организация передачи потокового видеоВначале на сервер посылается запросDESCRIBE,который означает, что сервер должен предоставить информацию о запрашиваемой услуге потокового видео (параметры кодирования, номера портов и др.). Видеосервер отвечает командой200 ОК,описывающей услугу в виде SDP-сообщения.После получения ответного сообщения ПТ передаёт на серверкомандуSETUP,в которой содержатся номера портов, через которые будет осуществлён приём потоков данных. Сервер подтверждает приём, отсылаяпользователю команду200 OK.59ДалеевыполняетсяпроцедуравторичнойактивацииPDP-контекста, в ходе которой определяется ряд параметров качестваобслуживания QoS, связанных с передачей потокового видео.

Определение и передача QoS-параметров может быть реализована с использованием управляющего протокола передачи данных в режимереального времени (RTCP, Real-time Transport Control Protocol). Такжев ходе процедуры вторичной активации PDP-контекста сеть резервирует физические ресурсы, которые будут использованы для передачивидеопотока. По завершении процедуры активации ПТ отсылает серверу командуPLAY,после чего сервер высылает пользователю подтверждение и можетначать передачу видеопотока с использованием протокола передачиданных в режиме реального времени (RTP, Real-time Transport Protocol).Однако воспроизведение видео в ПТ начинается не сразу. Длякомпенсации разброса значений временных задержек, с которымипользователю доставляются пакеты, на прикладном уровне реализован видеобуфер, по заполнении которого и начинается воспроизведение видео.

Понятно, что при хорошем качестве обслуживания, видеобуфер должен непрерывно заполняться новыми пакетами, так чтобывоспроизведение видео выполнялось непрерывно.1.5. КАЧЕСТВО ОБСЛУЖИВАНИЯ В СЕТЯХ LTEКонцепция системы QoS для сетей UMTS мобильной связи 3-гопоколения определена в спецификации TS 23.107, и используетсятакже для сетей LTE 4-го поколения.При разработке и внедрении системы качества обслуживания катрибутам такой системы предъявляются следующие общие требования. Количество и значения атрибутов должны быть таковы, чтобыобеспечить возможность многоуровневой градации пользователей.60 Использование механизма QoS не должно мешать политикеэффективного использования радиоресурсов, независимому развитиюбазовой сети и сети радиодоступа. Все атрибуты и их комбинации должны иметь однозначно определённые значения.Исходя из перечисленных общих требований к качеству обслуживания, в спецификациях сформулированы конкретные техническиетребования, касающиеся набора параметров QoS. Механизмы QoS функционируют в рамках одноранговой (peerto peer) модели организации связи в границах “пользовательский терминал — сетевой шлюз”, обеспечивая взаимно-однозначное отображение между сетевыми услугами и внешними приложениями. Управление качеством обслуживания осуществляется на основеконечного, по возможности, минимального набора параметров QoS,поддерживающих эффективное использование радиоресурсов, а также ассиметричное функционирование сквозных каналов. Методы управления QoS реализуются на основе последовательных сессий, применительно к пакетной передачи данных, в томчисле, к мультипотоковой передаче, когда несколько различных потоков имеют один и тот же адрес. Сетевые ухудшения и усложнения, вызванные внедрением системы качества обслуживания, должны быть по возможности минимизированы, также, как и количество дополнительной информации, хранимой и передаваемой в сети. Пользовательские приложения должны иметь возможность индикации значений QoS при передаче данных в различных сетевых узлах. Система качества обслуживания должна быть динамической,позволяющей изменять параметры QoS в течение активной сессии.Рассмотрим архитектуру системы качества обслуживания и передачу услуг в рамках такой системы, рассматривая, для определённости, случай, когда связь осуществляется между оконечным оборудо61ванием (ОО), подключённым к пользовательскому терминалу мобильной сети, и терминальным оборудованием, расположенным вовнешней пакетной сети (рис.

Характеристики

Список файлов книги