СПОСОБ ОБРАБОТКИ УВЕДОМЛЕНИЯ АКТИВНОЙ ДОСТАВКИ В СЛУЖБЕ МУЛЬТИМЕДИЙНЫХ СООБЩЕНИЙ

Область техники

Настоящее изобретение относится к технологии передачи мультимедийной информации и, в частности, к способу PUSH-уведомления (уведомления активной доставки) в службе мультимедийных сообщений.

Уровень техники

Служба мультимедийных сообщений (MMS) является развитием службы коротких сообщений (SMS) и службы передачи графической информации; она обеспечивает возможность передачи полнофункционального контента, включая графику, звук, видео, данные и текст. Служба MMS позволяет передавать мультимедийную информацию в реальном времени между мобильными телефонами, а также между мобильными телефонами и Интернетом. Сетевым элементом, обеспечивающим доставку мультимедийных сообщений в сети, является центр обработки мультимедийных сообщений (MMSC).

Центр MMSC в процессе передачи мультимедийного сообщения активирует поток доставки, когда центр MMSC получает мультимедийное сообщение, отправленное терминалом службы MMS, поставщиком платных услуг (VASP) или почтовым сервером. Реализация потока включает две фазы: процесс PUSH-уведомления и процесс поиска указанного сообщения. Процесс PUSH-уведомления службы MMS в общем состоит в том, что центр MMSC подготавливает PUSH-уведомление в виде одного или нескольких коротких сообщений и передает это уведомление на получающий терминал вместе с содержащейся в PUSH-уведомлении привязанной информацией мультимедийного сообщения, а именно адресной информацией, требующейся принимающему терминалу для поиска мультимедийного сообщения, идентификатором средства распределения, предметом мультимедийного сообщения и адресной информацией принимающего терминала, причем адресная информация содержит адрес центра MMSC и уникальный идентификатор мультимедийного сообщения в этом центре MMSC. Принимающий терминал активирует процесс поиска сообщения, когда он принимает короткие сообщения и объединяет их в PUSH-уведомление, т.е. принимающий терминал инициирует запрос поиска сообщения в центр MMSC, который хранит мультимедийные сообщения в соответствии с адресной информацией, содержащейся в PUSH-уведомлении, и осуществляет поиск этих сообщений.

Согласно спецификациям международных стандартов сообщение PUSH-уведомления содержит:

1) TID: идентификатор транзакции, длина 1 байт;

2) Type: тип сообщения; Поле Type указывает, что сообщение является PUSH-уведомлением, если значение равно 0×06. Длина поля Type составляет 1 байт;

3) HeaderLen: длина заголовка сообщения; Поле HeaderLen использует коды uintvar с длиной 1 байт;

4) ContentType: тип тела сообщения; в случае PUSH-уведомления службы MMS имеются две возможности выражения: одна возможность заключается в использовании символьной строки application/vnd.wap.mms-message, занимающей 32 байта; другая возможность заключается в использовании двоичных кодов 0×3Е, занимающих 1 байт. В большинстве случаев для поля ContentType предпочтительно использовать символьную строку.

5) Headers: обозначает контент заголовка сообщения; длина поля Header равна разности между значением поля HeaderLen и длиной поля ContentType;

6) X-Mms-Message-Type: обозначает тип модуля данных протокола службы MMS; Значение сообщения о PUSH-уведомлении составляет 130, его длина - 1 байт;

7) X-Mms-Transaction-ID: внутренний идентификатор, назначаемый центром MMSC, чтобы обеспечить принимающей стороне возможность правильного нахождения мультимедийного сообщения; его длину и правило кодирования задает и идентифицирует центр MMSC, длина является переменной;

8) X-Mms-MMS-Version: обозначает версию службы MMS, длина составляет 2 байта;

9) From: обозначает инициатора мультимедийного сообщения; минимальная длина - 4 байта;

10) Subject: обозначает предмет мультимедийного сообщения. После того как мультимедийное сообщение закодировано с кодировкой UTF-8, минимальная длина поля Subject составляет 6 байт, если длина мультимедийного сообщения не менее 31 байта, в противном случае минимальная длина поля Subject составляет 5 байт;

11) X-Mms-Message-Class: обозначает класс мультимедийного сообщения; например, мультимедийное сообщение может представлять личную информацию, рекламную информацию или данные; длина поля X-Mms-Message-Class составляет 2 байта;

12) X-Mms-Message-Size: обозначает длину мультимедийного сообщения; длина этого поля может быть 5 или 6 байтов после использования длинных целых кодов;

13) X-Mms-Expiry: обозначает срок действия мультимедийного сообщения; длина этого поля 7 или 8 байтов;

14) X-Mms-Content-Location: обозначает адрес единообразного идентификатора ресурса (URI) для мультимедийного сообщения, содержащего по меньшей мере адрес центра MMSC и идентификатор транзакции этого сообщения; адресом центра MMSC может быть IP-адрес и номер порта или доменное имя с переменной длиной; поэтому длина этой части также является переменной.

Сторона, инициирующая мультимедийное сообщение, посылает PUSH-уведомление, подготовленное в описанном выше формате, принимающей стороне через различные промежуточные звенья. PUSH-уведомление подразумевает также проведение поиска сообщения перед завершением доставки мультимедийного сообщения. Процессы доставки мультимедийного сообщения в сетях глобальной системы мобильной связи (GSM), пакетной радиосвязи общего назначения (GPRS), широкополосного многостанционного доступа с кодовым разделением каналов (WCDMA), доступа CDMA95, доступа CDMA2000 и в других сетях являются схожими; поэтому в данной заявке в качестве примера взят процесс доставки мультимедийного сообщения системы GSM.

PUSH-уведомление мультимедийного сообщения может быть доставлено через шлюз протокола беспроводных приложений (WAPGW) или непосредственно через центр MMSC.

На фиг.1 проиллюстрирован процесс отправки инициирующей стороной (такой как терминал службы MMS, поставщик VASP или почтовый сервер) мультимедийного сообщения с использованием PUSH-уведомления известного формата принимающей стороне через шлюз WAPGW; причем данный процесс включает:

Этапы 11˜12: сторона, инициирующая мультимедийное сообщение, передает подлежащее доставке сообщение в центр MMSC. Получив это мультимедийное сообщение, центр MMSC активирует поток PUSH-уведомления, чтобы выдать это уведомление на терминал принимающей службы MMS.

Процесс выдачи PUSH-уведомления включает:

Этап 1201: центр MMSC посылает на шлюз WAPGW сообщение push_message, содержащее PUSH-уведомление, и записывает число выполнений этого этапа.

Этап 1202: шлюз WAPGW, получив сообщение push_message, возвращает ответ push_response в центр MMSC.

Этап 1203: шлюз WAPGW использует интерфейсный протокол между шлюзом WAPGW и системой коротких сообщений, чтобы упаковать PUSH-уведомление, содержащееся в сообщении push_message, в короткое сообщение; отправляет инициирующее сообщение submit_sm в систему коротких сообщений; и записывает число выполнений этого этапа.

Система коротких сообщений содержит центр службы коротких сообщений (SMSC) и шлюз коротких сообщений. Интерфейсный протокол между шлюзом WAPGW и системой коротких сообщений может представлять собой протокол одноранговых коротких сообщений (SMPP), универсальный компьютерный протокол (UCP), протокол доставки сообщений компьютерного интерфейса (CIMD) или другой протокол такого же типа.

Этап 1204: система коротких сообщений после получения сообщения submit_sm возвращает ответ submit_sm_resp в шлюз WAPGW.

Затем система коротких сообщений выдает короткое сообщение принимающей стороне - центру MSC/терминалу службы MMS.

Этап 1205: система коротких сообщений определяет адрес домашнего регистра местоположения (HLR) принимающего терминала службы MMS в соответствии с адресной информацией принимающей стороны, содержащейся в PUSH-уведомлении, находящемся в сообщении submit_sm; далее система отправляет запрос маршрутизатора map_sri_for_sm_req в регистр HLR и записывает количество выполнений этого этапа.

Этап 1206: Регистр HLR, получив сообщение с запросом map_sri_for_sm_req, возвращает в систему коротких сообщений сообщение с ответом маршрутизатора map_sri_for_sm_resp, содержащее адрес центра коммутации мобильной связи (MSC), в зоне которого находится в настоящий момент принимающая сторона.

Этапы 1207˜1208: система коротких сообщений посылает в виде короткого сообщения принимающей стороне сообщение с запросом map_mt_fwd_sm_req, чтобы инициировать выдачу короткого сообщения, содержащего PUSH-уведомление в соответствии с информацией маршрутизатора, находящейся в сообщении с ответом map_sri_for_sm_resp; принимающая сторона возвращает сообщение map_mt_fwd_sm_resp в систему коротких сообщений, показывающее, успешно ли было выдано PUSH-уведомление. Затем принимающая сторона определяет, получил ли центр SMSC для заданного количества повторов выдачи сообщение map_mt_fwd_sm_resp с информацией, показывающей, что PUSH-уведомление было успешно выдано; если "да", то происходит выполнение этапа 1209; в противном случае система коротких сообщений выбирает, требуется ли повторить выдачу указанного уведомления, и выбирает количество таких попыток в соответствии с внутренней стратегией повтора выдачи; при повторе выдачи уведомления системой коротких сообщений эта система определяет, превысило ли число выполнений этапа 1205 заданную величину; если число выполнений этапа 1205 превысило заданное число выполнений, то система констатирует, что выдача PUSH-уведомления закончилась неудачей, и выполняет этап 1209; если количество выполнений этапа 1205 не превысило заданное значение, то система коротких сообщений использует стратегию повтора выдачи и возвращается к этапу 1205.

Этим поток, в ходе которого система коротких сообщений выдает короткое сообщение на центр MSC/терминал службы MMS принимающей стороны, завершается.

Этапы 1209˜1210: система коротких сообщений посылает на шлюз WAPGW сообщение deliver_sm, показывающее, успешно ли выдано PUSH-уведомление. Получив сообщение deliver_sm, шлюз WAPGW возвращает в систему коротких сообщений ответ с отчетом о доставке deliver_sm_resp и определяет, успешно ли выдано PUSH-уведомление в соответствии с сообщением deliver_sm; если "да", то происходит выполнение этапа 1211; в противном случае шлюз WAPGW определяет, требуется ли выполнить повтор выдачи уведомления в соответствии с внутренней стратегией повтора выдачи; шлюз WAPGW при повторе выдачи уведомления определяет, превысило ли число выполнений этапа 1203 заданное значение; если число выполнений этапа 1203 превысило заданное число выполнений, то шлюз WAPGW констатирует, что выдача PUSH-уведомления закончилась неудачей, и выполняет этап 1211; если количество выполнений этапа 1203 не превысило заданное значение, то шлюз WAPGW использует стратегию повтора выдачи и возвращается к этапу 1203.

Этапы 1211˜1212: Шлюз WAPGW посылает в центр MMSC сообщение с результатом уведомления resultnotification-message, показывающее, успешно ли было выдано PUSH-уведомление. Центр MMSC, получив сообщение с результатом уведомления, возвращает в шлюз WAPGW сообщение с ответом resultnotification-response и в соответствии с полученным сообщением определяет, успешно ли было выдано PUSH-уведомление; если "да", то центр MMSC завершает поток PUSH-уведомления; в противном случае центр MMSC выбирает, требуется ли повторить выдачу указанного уведомления, и выбирает количество таких повторов в соответствии с внутренней стратегией повтора выдачи; при повторе выдачи уведомления центром MMSC этот центр определяет, превысило ли число выполнений этапа 1201 заданную величину; если число выполнений этапа превысило заданное число повторов, то центр MMSC констатирует, что выдача PUSH-уведомления закончилась неудачей, завершает поток PUSH-уведомления и выполняет этап 17; если число выполнений этапа 1201 не превысило заданное значение, то центр MMSC использует стратегию повтора выдачи и возвращается к этапу 1201.

Этим поток PUSH-уведомления завершается.

Этапы 13˜16: Центр MMSC взаимодействует с принимающим центром MSC/терминалом службы MMS, чтобы найти сообщение.

Этап 17: центр MMSC посылает инициирующей стороне отчет о состоянии доставки мультимедийного сообщения, показывающий, успешно ли получила принимающая сторона мультимедийное сообщение.

После того как выдача PUSH-уведомления завершена, инициирующая и принимающая стороны отыскивают мультимедийное сообщение в соответствии с потоком поиска сообщения (этапы 13-17), чтобы завершить его доставку.

Первым описан поток выдачи мультимедийного сообщения через шлюз WAPGW, следующим - поток выдачи мультимедийного сообщения непосредственно через центр MMSC.

На фиг.2 проиллюстрирован способ выдачи принимающей стороне мультимедийного сообщения непосредственно через центр MMSC с использованием PUSH-уведомления существующего формата, включающий:

Этапы 21˜22: Сторона, инициирующая мультимедийное сообщение, передает его в центр MMSC. Получив это мультимедийное сообщение, центр MMSC активирует процесс PUSH-уведомления и выдает это уведомление принимающей стороне.

При этом процесс PUSH-уведомления включает:

Этап 2201: центр MMSC использует интерфейсный протокол, взаимодействующий с системой коротких сообщений для упаковки PUSH-уведомления в короткое сообщение; затем центр MMSC посылает в систему коротких сообщений при помощи интерфейсного протокола инициирующее сообщение submit_sm, содержащее это PUSH-уведомление, и записывает число выполнений этого этапа.

Этап 2202: система коротких сообщений, получив сообщение submit_sm, возвращает в центр MMSC сообщение с ответом submit_sm_resp.

Затем система коротких сообщений выдает короткое сообщение принимающей стороне.

Этап 2203: система коротких сообщений определяет адрес регистра HLR принимающей стороны в соответствии с адресной информацией принимающей стороны, содержащейся в PUSH-уведомлении, находящемся в сообщении submit_sm; далее система отправляет сообщение с запросом маршрутизатора map_sri_for_sm_req в регистр HLR и записывает число выполнений этого этапа.

Этап 2204: получив сообщение map_sri_for_sm_req, регистр HLR возвращает в систему коротких сообщений сообщение с ответом маршрутизатора map_sri_for_sm_resp, указывающее адрес центра MSC, в зоне которого находится в настоящий момент принимающая сторона.

Этапы 2205˜2206: система коротких сообщений посылает в виде короткого сообщения принимающей стороне сообщение с запросом map_mt_fwd_sm_req, чтобы инициировать выдачу короткого сообщения, содержащего PUSH-уведомление в соответствии с информацией маршрутизатора, находящейся в сообщении с ответом map_sri_for_sm_resp; принимающая сторона возвращает в систему коротких сообщений сообщение map_mt_fwd_sm_resp, показывающее, успешно ли было выдано PUSH-уведомление. Затем система коротких сообщений определяет для заданного количества повторов выдачи, получила ли она сообщение map_mt_fwd_sm_resp с информацией, показывающей, что PUSH-уведомление было успешно выдано; если "да", то происходит выполнение этапа 2207; в противном случае система коротких сообщений выбирает, требуется ли повторить выдачу указанного уведомления, и выбирает количество таких попыток в соответствии с внутренней стратегией повтора выдачи; система коротких сообщений при повторе выдачи уведомления определяет, превысило ли число выполнений этапа 2203 заданную величину; если число выполнений этапа 2203 превысило заданную величину, то система констатирует, что выдача PUSH-уведомления закончилась неудачей, и выполняет следующий этап; если количество выполнений этапа 2203 не превысило заданное значение, то система коротких сообщений использует стратегию повтора выдачи и возвращается к этапу 2203.

Этим поток, в ходе которого система коротких сообщений выдает короткое сообщение принимающей стороне, завершается.

Этапы 2207˜2208: система коротких сообщений посылает в центр MMSC сообщение с отчетом о доставке deliver_sm, показывающее, успешно ли выдано PUSH-уведомление. Получив сообщение deliver_sm, центр MMSC возвращает в систему коротких сообщений ответ с отчетом о доставке deliver_sm_resp и определяет, успешно ли выдано PUSH-уведомление согласно отчету о доставке; если "да", то он завершает поток PUSH-уведомления; в противном случае центр MMSC решает, требуется ли повторить выдачу указанного уведомления, и выбирает количество таких попыток в соответствии с внутренней стратегией повтора выдачи; центр MMSC при повторе выдачи уведомления определяет, превысило ли число выполнений этапа 2201 заданное значение; если число выполнений этапа 2201 превысило заданное значение, то центр MMSC констатирует, что выдача PUSH-уведомления закончилась неудачей, и завершает поток доставки мультимедийного сообщения, а также определяет, что доставка мультимедийного сообщения закончилась неудачей, и выполняет этап 27; если количество выполнений этапа 2201 не превысило заданное значение, то центр MMSC использует стратегию повтора выдачи и возвращается к этапу 2201.

Этим поток PUSH-уведомления завершается.

Этапы 23˜26: центр MMSC взаимодействует с принимающим центром MSC/терминалом службы MMS, чтобы найти сообщение.

Этап 27: центр MMSC посылает инициирующей стороне отчет о состоянии доставки мультимедийного сообщения, показывающий, успешно ли получила принимающая сторона мультимедийное сообщение.

После того как выдача PUSH-уведомления завершилась, инициирующая и принимающая стороны отыскивают мультимедийное сообщение в соответствии с потоком поиска сообщения (этапы 23-27), чтобы завершить доставку этого мультимедийного сообщения.

Сети GSM, GPRS, WCDMA, CDMA95, CDMA2000 и другие мобильные и стационарные сети могут использовать режим сети, проиллюстрированный на фиг.2, согласно которому центр MMSC использует соответствующий интерфейсный протокол для установления непосредственной связи с системами коротких сообщений различных мобильных или стационарных сетей для осуществления доставки мультимедийного сообщения. Например, в сети CDMA центр MMSC может быть непосредственно соединен с ее центром коротких сообщений (МС), чтобы выполнить доставку мультимедийного сообщения.

Два упомянутых выше потока показывают, что PUSH-уведомление является ключевым для всей службы MMS - оно необходимо для нормального получения информации принимающей стороной. Если контент PUSH-уведомления превышает максимальную длину, допускаемую для короткого сообщения, то шлюз WAPGW или система коротких сообщений может разделить это уведомление на несколько коротких сообщений для последующей передачи. Если шлюз WAPGW разделил PUSH-уведомление, то для завершения доставки этого уведомления указанные выше этапы 1203˜1210 необходимо выполнить несколько раз. Если PUSH-уведомление разделено системой коротких сообщений, то для завершения доставки этого уведомления необходимо несколько раз выполнить указанные выше процессы 1205˜1208 или 2203˜2206.

Более конкретно, согласно известному из уровня техники способу обработки PUSH-уведомления, если полная длина этого уведомления превышает 140 байтов, то это уведомление из-за ограничения максимальной длины короткого сообщения 140 байтами может быть разделено для доставки на несколько коротких сообщений, и принимающая сторона должна ждать прихода всех этих коротких сообщений, содержащих одно PUSH-уведомление, прежде чем она сможет собрать их все в полное уведомление.

Использование множества коротких сообщений, несущих одно PUSH-уведомление, приводит к появлению сложных многочисленных связей в потоке этого уведомления. Кроме того, если доставка короткого сообщения заканчивается неудачей, то трудно скоординировать механизмы повтора выдачи центра MMSC и шлюза WAPGW с существующим шлюзом WAPGW; и невозможно точно определить то короткое сообщение, которое должно быть повторено. Как результат, доля успешных попыток для PUSH-уведомления является невысокой и качество обслуживания для сервиса мультимедийных сообщений серьезно ухудшается.

Разделение одного PUSH-уведомления на множество коротких сообщений ведет к появлению многочисленных промежуточных связей и к высоким эксплуатационным расходам.

Сущность изобретения

Таким образом, предложен способ обработки PUSH-уведомления (уведомления активной доставки), обеспечивающий уменьшение задержки между выдачей и получением этого уведомления.

Способ включает следующие этапы:

помещение в PUSH-уведомление несжимаемых полей этого уведомления, сжатие поля Type, обозначающего тип сообщения, и поля идентификатора транзакции TID внутреннего идентификатора и помещение сжатого поля Type и сжатого поля TID в это PUSH-уведомление;

определение, может ли PUSH-уведомление быть выдано как одно короткое сообщение; если это PUSH-уведомление может быть выдано как одно короткое сообщение, то выдачу этого уведомления осуществляют в виде одного короткого сообщения; если это PUSH-уведомление не может быть выдано как одно короткое сообщение, то выдачу этого уведомления осуществляют в виде двух коротких сообщений;

определение, имеются ли незанятые байты в этом коротком сообщении; если незанятые байты в этом коротком сообщении имеются, то определение, может ли поле From, обозначающее инициатора сообщения, быть помещено в PUSH-уведомление в соответствии с числом незанятых байтов в коротком сообщении, и определение, может ли быть выполнено сжатие поля Subject и его помещение в PUSH-уведомление в соответствии с числом незанятых байтов в коротком сообщении; если поле From уже вставлено в короткое сообщение и в этом коротком сообщении недостаточно байтов для вставки поля Subject, то исключение поля Subject; если в коротком сообщении имеются незанятые байты, но поле From не помещается в это сообщение, то исключение поля From и поля Subject, которые не помещаются в PUSH-уведомление.

Несжимаемые поля PUSH-уведомления, помещаемые в PUSH-уведомление, содержат 10 полей, за исключением поля Type, обозначающего тип сообщения, поля TID, обозначающего внутренний идентификатор, поля From, обозначающего инициатора сообщения, и поля Subject, обозначающего предмет сообщения.

Процесс сжатия поля Type, обозначающего тип сообщения, включает этап выражения поля Type, обозначающего тип сообщения, двоичным кодом, занимающим 1 байт.

Процесс сжатия поля TID внутреннего идентификатора включает следующие этапы:

исключение центрального идентификатора службы мультимедийных сообщений во внутреннем идентификаторе и выражение временной части в секундах;

исключение центрального идентификатора в поле внутреннего идентификатора, выражение временной части в секундах и преобразование поля внутреннего идентификатора в коды 64-ричной системы счисления.

Процесс определения, может ли это PUSH-уведомление быть выдано как одно короткое сообщение, включает этап определения, меньше ли длина PUSH-уведомления 140 байтов; если длина PUSH-уведомления меньше 140 байт, то это уведомление может быть выдано в одном коротком сообщении; в противном случае PUSH-уведомление не может быть выдано как одно короткое сообщение.

Процесс определения возможности помещения поля инициатора From в PUSH-уведомление, сжатия поля Subject и помещения его в это уведомление включает следующие этапы:

определение, достаточно ли незанятых байтов в коротком сообщении для помещения поля From; если их недостаточно, то исключение полей From и Subject и завершение процессов PUSH-уведомления; в противном случае помещение поля From в PUSH-уведомление;

определение, можно ли для поля Subject использовать набор символов или вид кодирования, уменьшающий длину кода этого поля; если для поля Subject можно использовать набор символов или вид кодирования, уменьшающий длину кода этого поля, то использование для выражения поля Subject этого набора символов или вида кодирования, уменьшающего длину кода; в противном случае использование первоначального набора символов или вида кодирования;

определение, достаточно ли незанятых байтов в коротком сообщении, содержащем поле From, для размещения набора символов или вида кодирования поля Subject и кодов, соответствующих по меньшей мере одному символу в коде символьной строки поля Subject; если незанятых байтов в коротком сообщении, содержащем поле From, достаточно для размещения набора символов или вида кодирования поля Subject и кодов, соответствующих по меньшей мере одному символу в коде символьной строки поля Subject, то помещение этого набора символов или вида кодирования в PUSH-уведомление и последовательное помещение кодов, соответствующих отдельному символу кода символьной строки, в PUSH-уведомление согласно незанятым байтам в коротком сообщении; в противном случае исключение поля Subject и завершение процесса PUSH-уведомления.

Процесс последовательного помещения кодов, соответствующих отдельным символам части кодов символьной строки, в PUSH-уведомление включает следующие этапы:

определение байтов, занятых кодами, чтобы выразить один отображаемый символ в существующем виде кодирования;

вычисление числа "m" отображаемых символов, которые может вместить короткое сообщение в соответствии с незанятыми байтами этого короткого сообщения, содержащего вид кодирования набора символов и байты кодирования, определенные в соответствии с имеющимся видом кодирования;

последовательное помещение в PUSH-уведомление кодов, соответствующих символам с первого до "m" кодовой части строки символов поля Subject.

Также данное изобретение обеспечивает сжатие некоторых полей PUSH-уведомления, вследствие чего они могут занимать меньше байтов и поэтому это уведомление при отправке можно разместить максимум в двух коротких сообщениях. Варианты выполнения данного изобретения обеспечивают следующие преимущества.

Данное изобретение обеспечивает включение 10 несжимаемых полей, а также полей ContentType и X-Mms-Transaction-ID PUSH-уведомления, сохраняя при этом целостность ключевой информации этого уведомления.

Поскольку сжимаемые поля в PUSH-уведомлении занимают меньше байтов, то данное изобретение уменьшает общую длину этого уведомления, благодаря чему уведомление можно передать максимум двумя короткими сообщениями. Таким образом, заявленный способ позволяет уменьшить объем передаваемых данных, сократить временные задержки и увеличить эффективность передачи.

Поскольку PUSH-уведомление можно разместить максимум в двух коротких сообщениях, то данное изобретение позволяет уменьшить время выполнения потока выдачи коротких сообщений в процессе доставки мультимедийных сообщений, сократить время исполнения промежуточных связей и уменьшить эксплуатационные расходы.

Поскольку PUSH-уведомление можно разместить только в одном или в двух коротких сообщениях, то данное изобретение позволяет легко определить то короткое сообщение, которое следует повторить, если доставка этого короткого сообщения закончилась неудачей.

Краткое описание чертежей

Фиг.1 изображает блок-схему, иллюстрирующую традиционный поток выдачи мультимедийного сообщения через шлюз WAPGW.

Фиг.2 изображает блок-схему, иллюстрирующую традиционный поток мультимедийного сообщения непосредственно через центр MMSC.

Фиг.3 изображает общую блок-схему, иллюстрирующую способ обработки PUSH-уведомления согласно одному из вариантов данного изобретения.

Фиг.4 изображает блок-схему, иллюстрирующую поток, выполняющий сжатие поля Subject согласно одному из вариантов данного изобретения.

Варианты выполнения изобретения

Далее сущность настоящего изобретения поясняется на примере предпочтительных вариантов его выполнения, детально описанных со ссылкой на приложенные чертежи.

Варианты выполнения изобретения относятся к способу обработки PUSH-уведомления в службе мультимедийных сообщений; их ключевая идея состоит в следующем: выбрать в PUSH-уведомлении некоторые опциональные или имеющие переменную длину поля и сжать их, в результате чего это уведомление может быть передано не более чем двумя короткими сообщениями.

Описание заявленного способа обработки PUSH-уведомления приведено ниже на примере проиллюстрированных на фиг.3 и 4 процессов.

Как показано на фиг.3, заявленный способ обработки PUSH-уведомления в службе мультимедийных сообщений включает, согласно одному из вариантов изобретения, следующие этапы:

Этап 301: помещение несжимаемых полей в PUSH-уведомление.

В соответствии со спецификациями международных стандартов PUSH-уведомление содержит 14 полей. 10 полей, отличные от полей ContentType, X-Mms-Transaction-ID, From и Subject, не могут менять вид своего выражения, и, следовательно, занимаемые ими байты не могут быть сжаты. Поэтому центр MMSC в процессе обработки PUSH-уведомления помещает в PUSH-уведомление эти 10 несжимаемых полей.

Этап 302: сжатие полей ContentType и X-Mms-Transaction-ID и помещение их в PUSH-уведомление.

В соответствии со спецификациями международных стандартов имеются две возможности для выражения поля ContentType в PUSH-уведомлении: одна возможность состоит в выражении поля с использованием 32-байтной символьной строки application/vnd.wap.mms-message; другая возможность заключается в выражении поля с использованием двоичных кодов 0х3Е, занимающих 1 байт. В этом процессе данное поле отображается при помощи двоичных кодов, занимающих 1 байт; при этом экономится 31 байт.

Поле X-Mms-Transaction-ID имеет по существу следующую структуру: время + идентификатор центра обработки мультимедийных сообщений (MMSCID) + последовательный номер сообщения + конечная часть номера терминала + последовательный номер сессии. Назначение и занимаемые байты каждой части являются следующими:

Время: обозначает время доставки мультимедийного сообщения. Его формат: mmddHHMMSS. Поле Время занимает 10 байт.

Индикатор MMSCID: для идентификации центра MMSC. Это поле занимает 6 байт.

Последовательный номер сообщения: обозначает последовательный номер сообщения, занимает 5 байт.

Конечная часть номера терминала: последние две цифры номера мобильного телефона; используются для проверки правомерности; занимает 2 байта.

Последовательный номер сессии: внутренние ресурсы, назначенные центром MMSC мультимедийному сообщению; занимает 5 байтов.

Полная длина указанных выше пяти частей составляет 28 байт. Поле X-Mms-Transaction-ID в основном используется техническим персоналом при исследовательской работе; поэтому данное поле может быть сжато с использованием следующей стратегии:

а. Исключение идентификатора MMSCID: получив мультимедийное сообщение, терминал получает имя домена и может найти центр MMSC по этому имени; поэтому данная часть может быть опущена.

б. Преобразование формата времени из mmddHHMMSS, занимающего 10 байт, в целое число длиной 8 байт, т.е. выражение времени в секундах. Время обновляется 01 января каждого года, поэтому максимальное значение: 24 часа × 60 минут × 60 секунд × 366 дней = 31622400 секунд.

После выполнения указанных выше операций структура идентификатора X-Mms-Transaction-ID становится следующей: время (8 байт) + последовательный номер сообщения (5 байт) + конечная часть номера терминала (2 байта) + последовательный номер сессии (5 байт) = 20 байт. Если преобразовать указанные выше 20 байт в целое число, то максимальное значение будет 10²⁰-1; эти 20 байт займут 18 байт при использовании шестнадцатеричных кодов и 12 байт, если идентификатор X-Mms-Transaction-ID преобразован в 64-ричную систему счисления. Таким образом, после сжатия 64-ричная система счисления позволяет сэкономить 16 байт.

Этап 303: определение, меньше ли длина PUSH-уведомления 140 байт; если "да", то происходит выполнение этапа 304; в противном случае переход к этапу 305.

Поскольку одно короткое сообщение не может быть длиннее 140 байт, то на данном этапе происходит определение, может ли PUSH-уведомление быть помещено в одно короткое сообщение.

Этап 304: центр MMSC получает PUSH-уведомление, помещенное в одно короткое сообщение, затем выполняется этап 306.

Этап 305: центр MMSC имеет PUSH-уведомление, помещенное в два коротких сообщения.

Согласно этому процессу поля помещают сначала в первое сообщение, а затем - после заполнения первого сообщения - во второе сообщение.

Этапы 306˜307: определение, имеются ли незанятые байты в этом коротком сообщении; если "да", то происходит выполнение этапа 308; в противном случае исключают поля, которые не помещаются в PUSH-уведомление, и поток сжатия для этого уведомления завершается.

Если PUSH-уведомление может быть выдано в одном коротком сообщении, то способ определения наличия какого-либо незанятого байта в этом сообщении будет заключаться в следующем: определение, меньше ли 140 байтов полное число байтов, занятых 10-ю несжимаемыми полями и сжатыми полями ContentType и X-Mms-Transaction-ID; если "да", то констатация того, что в этом коротком сообщении имеются незанятые байты (незанятый байт); в противном случае констатация того, что в коротком сообщении нет незанятых байтов.

Если PUSH-уведомление помещается в два коротких сообщения, то определение того, имеются ли незанятые байты во втором коротком сообщении, осуществляют в ходе этого процесса.

Этап 308: сжатие полей From и Subject в соответствии с незанятыми байтами в коротком сообщении.

В ходе этого процесса центр MMSC определяет, имеется ли в сообщении место для полей From и Subject, и определяет вид сжатия поля Subject в соответствии с незанятыми байтами в коротком сообщении. Более конкретно, если незанятых байтов достаточно для помещения поля From, то центр MMSC помещает это поле в PUSH-уведомление и сжимает поле Subject в соответствии с оставшимися незанятыми байтами; в противном случае происходит завершение потока сжатия в PUSH-уведомлении.

Как следует из фиг.4, процесс сжатия полей From и Subject включает следующие этапы:

Этапы 401˜403: центр MMSC определяет, достаточно ли незанятых байтов в коротком сообщении для помещения поля From; если "да", то центр MMSC помещает поле From в PUSH-уведомление; в противном случае центр MMSC исключает поля From и Subject и завершает поток сжатия этих полей.

Если незанятых байтов в коротком сообщении достаточно для помещения целого поля From, то центр MMSC может поместить это поле в PUSH-уведомление. В других случаях центр MMSC выбирает исключение поля From.

Этапы 404˜405: определение, можно ли для поля Subject использовать другой набор символов или вид кодирования, которые могут уменьшить длину кода по сравнению с длиной кода этого поля Subject при уже используемом наборе символов или виде кодирования; если "да", то для сжатия поля Subject используют набор символов или вид кодирования уменьшенной длины кода и выполняют этап 406; в противном случае сразу выполняют этап 406.

Формат поля Subject является следующим: код символьной строки/вид кодирования набора символов. Для выражения заданного контента это поле может использовать различные наборы символов и виды кодирования, причем количество байт, занимаемых при различных наборах символов и видах кодирования также является различным. Поэтому при данном варианте заявленного способа используют следующую процедуру сжатия поля Subject: преобразование набора символов или вида кодирования, занимающих больше байтов, в такие, которые занимают меньше байтов, причем это преобразование проводят при условии сохранения неизменным контента поля. Например, преобразование символов кода UTF-8, дающих 6 байтов, в символы кода GB 2312, дающие 2 байта.

Этапы 406˜408: определения, достаточно ли незанятых байтов в коротком сообщении для того, чтобы поместить вид кодирования набора символов поля Subject и коды, соответствующие по меньшей мере одному символу поля Subject; если "да", то последовательное помещение поля набора символов или вида кодирования, а также кодов, соответствующих отдельным символам, выражающим текстовой контент поля Subject, в PUSH-уведомление в соответствии с числом незанятых байтов короткого сообщения; в противном случае исключение поля Subject и завершение потока сжатия полей From и Subject.

Ключевой идеей данного варианта сжатия поля Subject является усечение этого поля для уменьшения его длины. Более конкретно, вид кодирования набора символов поля Subject предназначен для выражения набора символов и вида кодирования, используемых кодами текстового контента Subject, и эта часть может быть сохранена полностью вместо того, чтобы быть обрезанной при сохранении. Часть с кодами символьной строки является определенным контентом поля Subject; эта часть с кодами символьной строки использует набор символов и вид кодирования, заданные в части вида кодирования набора символов. Если используемый набор символов является N-байтовым кодом, то каждый N-байтовый код выражает один отображаемый символ. Например, каждый символ использует 1-байтовые коды в наборе символов ANSI и 6-байтовые коды UTF-8 в наборе символов Unicode.

Поэтому, если незанятых байтов в коротком сообщении достаточно для того, чтобы поместить вид кодирования набора символов поля Subject и коды, соответствующие по меньшей мере одному символу, то центр MMSC помещает сначала в PUSH-уведомление часть с видом кодирования набора символов, а затем он последовательно помещает в это уведомление коды, соответствующие каждому символу, начиная с первого, в соответствии с незанятыми байтами в коротком сообщении. Если незанятые байты могут вместить набор символов или вид кодирования, но их недостаточно, чтобы вместить полные коды первого символа, то поле Subject будет исключено. Причина этого следующая: без кодов, обозначающих контент Subject, сами набор символов или вид кодирования являются бесполезными, даже если набор символов или вид кодирования присутствуют в поле Subject; если незанятых байтов недостаточно для того, чтобы вместить вид кодирования набора символов, то поле Subject будет исключено и поток сжатия полей From и Subject будет завершен.

Следует заметить, что поскольку каждый N-байтовый код выражает один отображаемый символ, то можно обеспечить, чтобы коды символьной строки, помещенные в PUSH-уведомление, были целочисленным кратным для N байтов, т.е. последние N байтов, помещенные в это уведомление, могут быть кодом того же самого первоначального символа. Если коды последнего первоначального символа не могут быть сохранены полностью, то все байты кода данного символа исключаются. Например, если имеется К незанятых байтов в коротком сообщении, то центр MMSC проводит операцию округления частного от деления К на N; если результатом округления является "m", то коды, соответствующие символам с первого до "m" кодовой части символьной строки поля Subject, помещаются в PUSH-уведомление.

В способе обработки PUSH-уведомления в соответствии с этим уведомлением, если мультимедийное сообщение доставляется через шлюз WAPGW, то сжатие поля ContentType выполняет шлюз WAPGW, а другие поля сжимает центр MMSC; если мультимедийное сообщение доставляется в систему коротких сообщений непосредственно центром MMSC, то все поля сжимает этот центр.

Обработка PUSH-уведомления в службе мультимедийных сообщений согласно заявленному способу позволяет эффективно уменьшить общую длину и сократить число занятых битов, что упрощает поток доставки мультимедийных сообщений. В случае сжатого PUSH-уведомления мультимедийного сообщения этапы 1203˜1210, проиллюстрированные на фиг.1, выполняются не более двух раз до завершения доставки одного уведомления, если доставка мультимедийного сообщения происходит через шлюз WAPGW; если доставка мультимедийного сообщения происходит непосредственно через систему коротких сообщений, то, чтобы завершить доставку одного PUSH-уведомления, должны быть выполнены не более двух раз этапы 1205˜1208, проиллюстрированные на фиг.1, или этапы 2203˜2206, проиллюстрированные на фиг.2.

Сети GSM, GPRS, WCDMA, CDMA95, CDMA2000, а также другие мобильные и стационарные сети, поддерживают службу мультимедийных сообщений; поэтому предложенный способ подходит для обработки PUSH-уведомлений во всех указанных сетях.

Выше описаны только предпочтительные варианты данного изобретения. Их не следует рассматривать как ограничение патентных притязаний изобретения. Все модификации, замены и улучшения данного изобретения, при условии, что они отвечают его сути, должны расцениваться как попадающие в объем его правовой охраны.