МЕТОД ДЛЯ ОБРАБОТКИ КОМАНД АТ В СВЯЗИ С ПАКЕТНЫМ ДОМЕНОМ EPS Российский патент 2013 года по МПК H04W76/02 

Область техники, к которой относится изобретение

Настоящее раскрытие, в целом, относится к обработке команд АТ. В частности раскрыт метод, предназначенный для способствования использованию команд АТ, заданных для пакетного домена универсальной пакетной радиослужбы (GPRS), в связи с пакетным доменом развитой пакетной системы (EPS).

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

Комплекты микросхем современной универсальной мобильной телекоммуникационной системы (UMTS) часто поддерживают две или более разные технологии радиодоступа (RAT), такие как GPRS, увеличенные скорости передачи данных для развития GSM (EDGE), широкополосный множественный доступ с кодовым разделением (WCDMA) и развитой высокоскоростной пакетный доступ (eHSPA). Независимо от активной в текущий момент RAT пользовательское оборудование (UE) UMTS с множеством RAT всегда соединено с некоторым доменом с коммутацией пакетов, пакетным доменом GPRS, для услуг с коммутацией пакетов. Таким образом, UE всегда может использовать одни и те же принципы для управления однонаправленным каналом и соединением протокола Internet (IP) и их назначения.

Управление однонаправленным каналом и соединением IP и их назначение в пакетном домене GPRS основаны на контекстах протокола пакетных данных (PDP) и содержат функции, предназначенные для активации, деактивации и модификации однонаправленных каналов и соединений, как, в целом, описано в технической спецификации (TS) 24.008 «Mobile Radio Interface Layer 3 Specification; Core Network Protocols; Stage 3» Проекта партнерства 3-го поколения (3GPP). Контекст PDP может быть рассмотрен как запись данных параметров, которые описывают конкретный однонаправленный канал или соединение с целевой сетью пакетных данных (PDN).

Множество приложений, выполняющихся в одном UE, могут требовать множества соединений с одной или более PDN таким образом, что может быть необходимым определять множество контекстов PDP. Эти множества контекстов PDP могут быть сгруппированы в так называемые первичные контексты PDP (также упомянутые далее в настоящей заявке как не вторичные контексты PDP) с одной стороны и вторичные контексты PDP с другой стороны.

Множество первичных контекстов PDP обеспечивают соединения с разными PDN, и каждый из них связан с уникальным адресом IP. Каждый вторичный контекст PDP создают на основе существующего первичного контекста PDP, и он обеспечивает соединение с той же PDN, что и этот первичный контекст PDP. Однако вторичный контекст PDP обычно связан с другой гарантией качества обслуживания (QoS), чем связанный первичный контекст PDP. Каждый первичный и вторичный контекст PDP имеет свой собственный однонаправленный канал радиодоступа (RAB) и его идентифицируют с помощью уникального идентификатора пункта доступа службы уровня сети (NSAPI), используемого как в пакетном домене GPRS, так и локально с помощью UE.

Поскольку адрес IP является одним и тем же для первичного контекста PDP и связанного с ним второго контекста PDP, узел поддержки GPRS шлюза (GGSN) в пакетном домене GPRS требует фильтра, чтобы маршрутизировать данные плоскости пользователя нисходящей линии связи в правильный RAB для первичного и вторичного контекстов PDP. Этот фильтр установлен с использованием так называемого шаблона потока трафика (TFT), передаваемого с помощью UE в сообщении запроса активировать вторичный контекст PDP в GGSN.

В существующих решениях схему управления однонаправленным каналом и соединением IP и их назначения, как определено в спецификациях 3GPP для линии связи между пакетным доменом GPRS и функциональными возможностями уровня 3 UE, также используют по отношению к приложениям, которые используют эти функциональные возможности уровня 3 для передачи данных. Такие приложения могут быть установлены либо внутренне в UE, либо внешне в терминальном устройстве, в которое UE предоставляет услуги модема.

Функциональные возможности управления однонаправленным каналом и соединением IP и их назначения могут быть предоставлены по отношению к приложениям (и терминальному устройству) с использованием интерфейса прикладного программирования (API). Для внутренних приложений API может быть реализован в виде так называемого API открытой платформы (OPA), как описано в публикации A. Ghost et al., «Open application environments in mobile devices: Focus on JME and Ericsson Mobile Platforms», Ericsson Review, Volume 82, 2005. В качестве альтернативы (например, для внешних приложений) Функциональные возможности управления однонаправленным каналом и соединением IP и их назначения могут быть предоставлены посредством API команд АТ в соответствии с 3GPP TS 27.007 «AT command set for User Equipments (UE)».

Как проиллюстрировано на фиг.1, команды АТ используют для управления функциями завершения мобильной связи (МТ), а также услугами в пакетном домене GPRS из оборудования терминала (ТЕ) посредством адаптера терминала (ТА). ТА, МТ и ТЕ могут быть осуществлены в виде отдельных или интегрированных объектов, как необходимо. 3GPP TS 27.007 определяет множество команд АТ для управления функциями МТ и услугами пакетного домена GPRS на основании контекстов PDP. Каждая команда АТ включает в себя параметр идентификации контекста (CID) в качестве ссылки на конкретный контекст PDP (и связанный RAB), к которому применяются команды АТ.

С редакцией 8 спецификаций 3GPP введены RAT долгосрочного развития (LTE) и развитая пакетная система (EPS). EPS является пакетным доменом, который будет использован с помощью UE в режиме LTE вместо традиционного пакетного домена GPRS.

Пакетный домен GPRS и пакетный домен EPS отличаются во многих аспектах. Например, вместо зависимости от контекстов PDP EPS основана на протоколе слоя не доступа (NAS), который определяет однонаправленные каналы по умолчанию, выделенные однонаправленные каналы и сервисные потоки данных (SDF, также называемые ресурсами однонаправленных каналов ESP), как описано в 3GPP TS 24.401 «GPRS enhancement for E-UTAN access» и 3GPP TS 24.301 «Non-access Stratum (NAS) protocol for Evolved Packet System (EPS); Core Network Protocols; Stage 3». Кроме того, процедуры установки однонаправленного канала EPS всегда инициируют с помощью стороны сети, в то время как в пакетном домене GPRS UE инициирует установку контекста PDP.

В EPS однонаправленный канал является базовым уровнем грануляции управления QoS (это означает, что весь трафик данных в одном и том же однонаправленном канале EPS предоставляет одинаковую гарантию QoS и что разные гарантии QoS могут быть предоставлены для разных однонаправленных каналов). Однонаправленный канал по умолчанию EPS устанавливают в соответствии с профилем QoS значений по умолчанию в процессе первоначального подключения UE к сети. В результате каждое UE имеет, по меньшей мере, один активный (по умолчанию) однонаправленный канал, чтобы ускорить инициализацию услуги. Дополнительные однонаправленные каналы EPS, соединенные с той же PDN, что и однонаправленный канал по умолчанию, называют выделенными однонаправленными каналами, и они обычно будут иметь другой профиль QoS, чем связанный однонаправленный канал по умолчанию.

Признак SDF EPS имеет сходства с признаком TFT GPRS в том, что каждый SDF может быть рассмотрен как связанный с пакетным фильтром или множеством пакетных фильтров (например, множеством пакетных фильтров восходящей линии связи и нисходящей линии связи). Кроме того, каждый SDF связан с конкретным профилем QoS. SDF основан на однонаправленном канале EPS, и несколько SDF с одинаковым профилем QoS могут создавать агрегированный SDF, отображенный в один однонаправленный канал EPS.

В противоположность GPRS, в которой решение относительно того, как отображать TFT и контексты PDP, выполняют в UE, в EPS сеть решает, как будет выполнено отображение. В результате сообщение запроса назначения ресурсов LTE для SDF, выданного с помощью UE с помощью сигнализации NAS, может возвратить либо новый выделенный однонаправленный канал EPS с запрошенным SDF, либо уже существующий (выделенный или по умолчанию) однонаправленный канал EPS с дополнительным SDF. В пакетном домене GPRS соответствующее сообщение запроса активации вторичного контекста PDP всегда бы возвращало новый (вторичный контекст) PDP со связанным RAB.

Обычно существует несколько возможностей того, как создать интерфейс по отношению к приложениям для управления однонаправленным каналом и соединением IP и их назначения в EPS. Первое решение могло бы повторно использовать концепцию, как задано в 3GPP TS 24.301, для интерфейса между функциональными возможностями уровня 3 UE и EPS, также в качестве базиса для интерфейса по отношению к приложениям, находящимся в UE или в терминальном устройстве, с которыми соединено UE. Такой интерфейс по отношению к приложениям содержал бы конкретные сообщения EPS, как сообщения запроса назначения ресурсов/освобождения однонаправленного канала, сообщения запроса активировать контекст однонаправленного канала EPS по умолчанию/выделенного однонаправленного канала EPS и т.д.

Несмотря на то, что это решение работало бы для UE с одной RAT, обеспечивающего только поддержку LTE, оно было бы не выгодно для UE с множеством RAT с возможностью LTE, которое соединяется с пакетным доменом EPS для однонаправленных каналов LTE и с пакетным доменом GPRS для однонаправленных каналов существующей UMTS. А именно, такое решение требовало бы, чтобы интерфейс по отношению к приложениям для управления однонаправленным каналом и соединением IP и их назначения был бы разным в зависимости от активной RAT. Однако во многих случаях было бы желательно, чтобы приложения могли запрашивать услуги, основанные на пакетах, независимо от активной RAT (т.е. чтобы приложения могли оставаться используемыми агностическими от используемой в текущий момент RAT).

Вторым противоположным решением могло бы быть программирование выделенного интерфейса, который может интерпретировать контексты PDP как однонаправленные каналы EPS и наоборот. В соответствии со вторым решением первичный контекст PDP мог бы быть интерпретирован как соответствующий однонаправленному каналу по умолчанию EPS, а вторичный контекст PDP мог бы быть интерпретирован как соответствующий выделенному однонаправленному каналу EPS. В результате интерфейс команд АТ для управления однонаправленным каналом LTE мог бы в значительной степени повторно использовать существующий интерфейс команд АТ для управления пакетным доменом GPRS.

Основными недостатками второго решения являются разные подходы активации однонаправленного канала, обсужденные выше. То есть для однонаправленных каналов пакетного домена GPRS UE принимает решение, должен ли быть активирован новый контекст PDP, в то время как для пакетного домена EPS именно сеть принимает решение об активации нового однонаправленного канала EPS. В результате определенные команды АТ, такие как запрос активации контекста PDP/однонаправленного канала EPS (+CGACT), должны бы быть интерпретированы по-разному в зависимости от активной RAT. Следовательно, дополнительная логическая схема должна быть осуществлена на стороне приложений, чтобы обрабатывать различия между RAT LTE с одной стороны и RAT существующей UMTS с другой стороны. Это также предполагает, что приложения, запрограммированные для пакетного домена GPRS, могли бы быть обязательно обновлены, чтобы поддерживать пакетный домен EPS.

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

Имеется потребность в эффективном методе, который позволит преодолеть, по меньшей мере, некоторые из проблем, описанных выше. А именно, требуется метод, который поспособствует использованию команд АТ, заданных для пакетного домена GPRS, в связи с пакетным доменом EPS.

В соответствии с первым аспектом, использованию команд АТ, заданных для пакетного домена GPRS, способствуют в связи с пакетным доменом EPS с помощью способа, содержащего этап определения в ответ на команду АТ, направленную на определение вторичного контекста PDP, SDF EPS на основании вторичного контекста PDP.

Таким образом, запрос вторичного контекста PDP может быть преобразован в запрос SDF EPS, принимая во внимание параметры запрошенного вторичного контекста PDP (относящиеся, например, к конкретному пакетному фильтру и/или профилю QoS). Такой подход позволяет повторное использование многих существующих команд АТ для управления пакетным доменом EPS без необходимости перепрограммирования существующих приложений. Следует заметить, что понятие «SDF EPS», как использованное в ранних редакциях спецификаций 3GPP, последовательно изменено в последних редакциях в понятия, такие как «поток трафика EPS» и «ресурс однонаправленного канала EPS». Таким образом, подразумевают, что понятие «SDF EPS», как использованное в настоящей заявке, также охватывает соответствующую концепцию современной редакции спецификаций 3GPP, такой как TS 24.301.

Запрос вновь определенного SDF EPS может быть передан с помощью сигнализации NAS в пакетный домен EPS и может возвратить новый выделенный однонаправленный канал EPS с запрошенным SDF или уже существующий однонаправленный канал EPS, связанный с этим SDF. Таким образом, SDF может быть определен в существующем соединении PDN. Как использовано в настоящем описании, понятие «однонаправленный канал EPS» относится как к однонаправленным каналам по умолчанию EPS, так и к выделенным однонаправленным каналам EPS. Таким же образом понятие «контекст PDP» относится как к не вторичным (т.е. первичным) контекстам, так и к вторичным контекстам PDP.

Каждая из некоторых или всех из команд АТ может включать в себя параметр CID в качестве ссылки на вторичный или не вторичный контекст PDP. В сценарии команды АТ, направленной на определение вторичного контекста PDP, параметр CID, включенный в эту команду АТ, может быть использован в качестве ссылки на определенный таким образом SDF.

Вновь определенный SDF может быть связан с однонаправленным каналом по умолчанию EPS, имеющим конкретное соединение PDN. В свою очередь, однонаправленный канал по умолчанию EPS может быть связан с выделенным параметром CID, и этот параметр CID однонаправленного канала по умолчанию EPS может быть связан с параметром CID вновь определенного SDF, чтобы связывать вновь определенный SDF со связанным однонаправленным каналом по умолчанию EPS и/или соединением PDN.

Способ дополнительно может содержать этап определения в ответ на команду АТ, направленную на определение не вторичного контекста PDP, однонаправленного канала по умолчанию EPS на основании не вторичного контекста PDP. Определение однонаправленного канала по умолчанию EPS может быть выполнено, принимая во внимание параметры не вторичного контекста PDP.

Команда АТ, направленная на определение не вторичного контекста PDP, может включать в себя параметр CID, и этот параметр CID может быть использован в качестве ссылки на вновь определенный однонаправленный канал по умолчанию EPS.

В осуществлении, в котором определяют выделенные команды АТ, чтобы предусмотреть определение вторичного, а также не вторичного контекстов PDP, параметры CID в соответственных командах АТ могут быть использованы в качестве ссылки как для SDF, так и однонаправленных каналов по умолчанию EPS, соответственно (например, в качестве ссылки на выделенные однонаправленные каналы EPS и однонаправленные каналы по умолчанию EPS). Однонаправленный канал по умолчанию EPS, на который ссылаются с помощью CID, может быть связан с «универсальными» пакетными фильтрами восходящей линии связи и нисходящей линии связи (например, вместо пакетных фильтров, определенных с помощью SDF). Кроме того, в случае, когда параметр CID используют в качестве ссылки на однонаправленный канал по умолчанию EPS, этот параметр CID, в частности, может быть использован в качестве ссылки на услугу или соединение по умолчанию в этом однонаправленном канале по умолчанию EPS. Кроме того или в качестве альтернативы этот параметр CID может быть использован в качестве ссылки на соединение PDP, связанное с этим однонаправленным каналом по умолчанию EPS.

Также может быть обеспечен механизм, предназначенный для определения выделенного однонаправленного канала EPS. В одном осуществлении выделенный однонаправленный канал EPS может быть определен в ответ на команду АТ, включающую в себя параметр CID. Затем параметр CID, включенный в команду АТ, может быть использован в качестве ссылки на вновь определенный выделенный однонаправленный канал EPS.

В иллюстративном сценарии однонаправленный канал EPS и один или более SDF в однонаправленном канале EPS установлены, принимая во внимание конкретную PDN. В этом сценарии ссылка на однонаправленный канал EPS и один или более SDF в однонаправленном канале EPS может быть сделана с помощью выделенных (т.е. других) CID.

Методы, представленные в настоящей заявке, могут быть выполнены с помощью пользовательского терминала с множеством RAT (т.е. с множеством режимов), поддерживающего RAT LTE и один или более RAT существующей UMTS. В режиме существующей UMTS (включающей в себя, например, GPRS и EDGE) каждая команда АТ может быть интерпретирована некоторым способом, как заданным для пакетного домена GPRS в существующих спецификациях (например, редакции 3 или более ранних 3GPP).

Пользовательский терминал с множеством RAT может выполнять передачу обслуживания (включающую в себя изменение RAT, или внутреннюю передачу обслуживания RAT) между доступом к сети LTE и доступом к сети существующей UMTS. В обычном сценарии передачи обслуживания из доступа к сети LTE к доступу к сети существующей UMTS могут быть определены n контекстов PDP, и n SDF могут быть связаны с одним однонаправленным каналом EPS в пакетном домене EPS до передачи обслуживания. После передачи обслуживания к доступу к сети существующей UMTS n контекстов PDP могут быть отображены в один контекст PDP по отношению к пакетному домену GPRS.

Из-за причин совместимости между профилями QoS GPRS и профилями QoS EPS может быть обеспечена логическая схема преобразования. С использованием логической схемы преобразования профиль QoS GPRS может быть преобразован в профиль QoS EPS и наоборот. Профиль QoS GPRS может быть совместимым с профилем QoS редакцией 7 или более ранними 3GPP, а профиль QoS EPS может быть совместимым с профилем QoS редакцией 8 или более поздними 3GPP. Логическая схема преобразования может быть использована для команды АТ, задающей профиль QoS, такой как любые из команд АТ +CGEQREQ, +CGEQMIN, +CGEQOS и +CGEQOSRDP. В одном осуществлении эти команды АТ применяют к SDF в случае доступа к сети LTE и к контексту PDP в случае доступа к сети существующей UMTS.

В качестве другой меры может быть обеспечена поддержка для одной или более дополнительных команд АТ, таких как +CGTFT, +CGCMOD и +CGACT. Эти дополнительные команды АТ могут быть применены к SDF и/или однонаправленным каналам EPS в случае доступа к сети LTE и к контекстам PDP в случае доступа к сети существующей UMTS (например, WCDMA).

Поддержка +CGACT может содержать посылку сообщения, относящегося к активации ресурса однонаправленного канала (например, сообщения запроса назначения ресурса однонаправленного канала), после активации SDF EPS или посылку сообщения, относящегося к освобождению ресурса однонаправленного канала (например, сообщения запроса модификации освобождения ресурса однонаправленного канала), после деактивации SDF EPS. Кроме того, в контексте команды АТ +CGACT сообщение запроса возможности соединения может быть послано после активации однонаправленного канала по умолчанию EPS или сообщение запроса разъединения PDN может быть послано после деактивации однонаправленного канала по умолчанию EPS.

Команда АТ может быть запрошена, инициирована с помощью приложения или принята из приложения с помощью пользовательского интерфейса. Приложение может быть выполнено локально в UE или с помощью внешнего терминального устройства, в которое UE предоставляет услуги модема. В одном осуществлении приложение является агностическим от того, существует ли соединение с пакетным доменом GPRS или пакетным доменом EPS. Иначе говоря, приложение не знает об активной в текущий момент RAT.

Приложение может быть ограничено первоначальной установкой, по меньшей мере, одного или более однонаправленных каналов EPS или одного или более SDF (например, на основании команд АТ, направленных на определение не вторичного и вторичного контекстов PDP, таких как +CGDCONT и +CGDSONT, соответственно). Это может подразумевать, что с использованием «традиционных» команд АТ, заданных для пакетного домена GPRS, будут установлены только однонаправленные каналы по умолчанию EPS и SDF. Что касается установки выделенного однонаправленного канала EPS, могут быть обеспечены дополнительные механизмы управления, если желательно. Например, выделенные однонаправленные каналы EPS могут быть обработаны непрозрачно для приложения или с помощью приложения таким образом, что приложение может конкретно запрашивать установку выделенного однонаправленного канала EPS, если желательно. В качестве примера новая команда АТ может быть определена явно для этой цели.

Способы, представленные в настоящей заявке, могут быть реализованы в виде программного обеспечения, в виде аппаратного обеспечения или с использованием подхода объединенного программного обеспечения/аппаратного обеспечения. Что касается аспекта программного обеспечения, предоставлен компьютерный программный продукт, содержащий части программного кода, предназначенные для выполнения этапов, представленных в настоящей заявке, когда компьютерный программный продукт выполняют в одном или более вычислительных устройствах. Компьютерный программный продукт может быть сохранен на компьютерно-считываемом записывающем носителе, таком как микросхема памяти, CD-ROM, жесткий диск и т.д. Кроме того, компьютерный программный продукт может быть предоставлен для загрузки с помощью сетевого соединения в такой записывающий носитель.

В соответствии с дополнительным аспектом предоставлено устройство, предназначенное для способствования использованию команд АТ, заданных для пакетного домена GPRS, в связи с пакетным доменом EPS. Устройство содержит компонент, выполненный с возможностью определять в ответ на команду АТ, направленную на определение вторичного контекста PDP, SDF EPS на основании вторичного контекста PDP. SDF EPS может быть определен в существующем соединении PDN.

Устройство дополнительно может содержать компонент, выполненный с возможностью использовать параметр CID, включенный в команду АТ и ссылающийся на вторичный контекст PDP, в качестве ссылки на SDF EPS. Кроме того, может быть предоставлен компонент, выполненный с возможностью определять в ответ на команду АТ, направленную на определение не вторичного контекста PDP, однонаправленный канал по умолчанию EPS на основании не вторичного контекста PDP. Этот компонент может быть адаптирован использовать параметр CID, включенный в команду АТ и ссылающийся на не вторичный контекст PDP, в качестве ссылки на однонаправленный канал по умолчанию EPS. Еще дополнительно с помощью устройства может быть составлен компонент, выполненный с возможностью использовать параметр CID, включенный в команду АТ, в качестве связи с соединением PDN, связанным с однонаправленным каналом по умолчанию EPS.

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

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

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

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

фиг.2 схематически иллюстрирует вариант осуществления пользовательского терминала с множеством RAT;

фиг.3 схематически иллюстрирует вариант осуществления контроллера команд АТ пользовательского терминала фиг.2;

фиг.4 схематически иллюстрирует вариант осуществления интерфейса прикладного программирования контроллера фиг.3;

фиг.5 изображает блок-схему последовательности этапов в соответствии с вариантом осуществления способа; и

фиг.6 схематически иллюстрирует вариант осуществления, визуализирующий идентификаторы пакетного домена в пакетных доменах EPS и GPRS.

Подробное описание изобретения

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

Например, несмотря на то, что варианты осуществления главным образом будут описаны в контексте конкретных команд АТ (таких как, в частности, +CGDCONT и +CGDSCONT), метод, раскрытый в настоящей заявке, также может быть применен к другим командам АТ, заданным с помощью 3GPP. Кроме того, настоящий метод не ограничен командами АТ, как определенными в спецификациях 3GPP. Например, метод также мог бы быть применен к командам, определенным для решений открытой платформы, основанных на ОРА, или любом другом API для управления однонаправленным каналом EPS/GPRS. Кроме того, несмотря на то, что варианты осуществления будут относиться к иллюстративному осуществлению LTE, без труда будет понятно, что метод, описанный в настоящей заявке, также может быть осуществлен в других сетях связи, таких как усовершенствованные сети LTE.

Кроме того, специалисты в данной области техники поймут, что услуги, функции и этапы, объясненные в настоящей заявке ниже, могут быть осуществлены с использованием программного обеспечения, функционирующего совместно с программируемым микропроцессором, интегральной схемы прикладной ориентации (ASIC), процессора цифровых сигналов (DSP) или универсального компьютера. Также будет понятно, что, несмотря на то, что варианты осуществления главным образом будут описаны в контексте способов и устройств, изобретение также может быть осуществлено в компьютерном программном продукте, а также в системе, содержащей процессор компьютера и память, соединенную с процессором, причем память кодируют с помощью одной или более программ, которые могут выполнять услуги, функции и этапы, раскрытые в настоящей заявке.

Фиг.2 изображает вариант осуществления пользовательского терминала (UE) 20, содержащего одно или множество приложений 22, а также котроллер 24 команд АТ, сконфигурированный с возможностью предоставления функциональных возможностей доступа к сети в приложение 22 на основании сигнализации команды АТ. UE сконфигурирован с возможностью поддержки доступа к сети с помощью множества RAT, включая, по меньшей мере, доступ к сети LTE и доступ к сети WCDMA или eHSPA. Как проиллюстрировано на фиг.2, таким образом, приложение 22 может быть обслужено либо в пакетном домене 30 EPS (доступа к сети LTE), либо в пакетном домене 40 GPRS (доступа к сети WCDMA или eHSPA). UE 20 дополнительно сконфигурирован с возможностью поддержки передачи обслуживания между RAT (IRAT), например, из WCDMA или eHSPA в LTE или наоборот.

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

Фиг.3 иллюстрирует конфигурацию контроллера 24 команд АТ UE 20. Как становится понятным из фиг.3, контроллер 24 команд АТ обычно содержит функциональные объекты, уже обсужденные выше со ссылкой на фиг.1. То есть контроллер 24 команд АТ содержит терминальное оборудование, или ТЕ 50, сконфигурированное с возможностью быть соединенным с приложением 22, адаптер терминала, или ТА 60, соединенный с ТЕ 50, а также мобильную оконечную нагрузку, или МТ 70, соединенную с ТА 60.

ТЕ 50 связывается с ТА 60 с помощью команд АТ и принимает соответствующие ответы. Для связи с ТЕ 50 ТА 60 содержит интерфейс 80 команд АТ в виде API. ТА 60 связывается с МТ 70 с помощью сообщений управления и статуса МТ, как в общих чертах проиллюстрировано на фиг.3. МТ 70 предоставляет функциональные возможности доступа к сети, например, в пакетный домен 30 EPS и пакетный домен 40 GPRS, проиллюстрированные на фиг.2. С этой целью МТ 70 передает и принимает сообщения сети с помощью активной RAT.

Внутренняя конфигурация интерфейса 80 команд АТ ТА 60 изображена на фиг.4. Как проиллюстрировано на фиг.4, интерфейс 80 команд АТ содержит интерпретатор 82 команд АТ, компонент 84 определения SDF EPS, компонент 86 определения однонаправленного канала по умолчанию EPS и компонент 88, предназначенный для обработки других команд АТ. Кроме того, выделенный компонент 90, 92 ссылки CID соединен с каждым из компонента 84 определения SDF EPS и компонента 86 определения однонаправленного канала по умолчанию EPS, как изображено на фиг.4. Оба компонента 90, 92 ссылки CID соединены с памятью 94, сконфигурированной с возможностью сохранения параметров CID корреляции отображения с SDF и однонаправленными каналами по умолчанию EPS. Отображение дополнительно может хранить параметры CID для выделенных однонаправленных каналов EPS. В одной реализации отображение имеет вид таблицы, в которой первая строка таблицы перечисляет отдельные параметры CID, а связанная вторая строка таблицы перечисляет отдельные идентификаторы SDF, однонаправленные каналы по умолчанию, выборочно выделенные однонаправленные каналы.

Работа интерфейса 80 команд АТ, проиллюстрированная на фиг.4, теперь будет описана со ссылкой на иллюстративный вариант осуществления способа, проиллюстрированный на блок-схеме 500 последовательности этапов фиг.5.

На первом этапе 502 интерпретатор 82 принимает команду АТ из ТЕ 50. Команда АТ может быть принята с помощью ТЕ 50 команды из приложения 22 или может быть сгенерирована с помощью ТЕ 50 после запроса, принятого из приложения 22 или пользовательского интерфейса (не изображен). В настоящем варианте осуществления допускают, что принятая команда АТ является либо командой АТ +CGDCONT, направленной на определение (первичного) контекста PDP, либо командой АТ +CGDSCONT, направленной на определение вторичного контекста PDP. В каждом случае команда АТ будет содержать параметр CID, а также параметры определения контекста PDP, указывающие, например, тип протокола пакетных данных (такой как IP или Х.25).

В случае, когда команда АТ направлена на определение первичного контекста PDP, следующий этап 502 обработки будет выполнен с помощью компонента 86 определения однонаправленного канала по умолчанию EPS. Иначе, т.е. если команда АТ направлена на определение вторичного контекста PDP, дополнительная обработка будет выполнена с помощью компонента 84 определения SDF EPS. В случае, когда принятая команда АТ является ни командой АТ +CGDCONT, ни командой АТ +CGDSCONT (случай, который специально не рассмотрен дополнительно в контексте фиг.5), дополнительную обработку выполняют с помощью компонента 88 обработки.

В дальнейшем сначала будет обсуждена цепочка обработки на фиг.5 для обработки +CGDCONT. На этапе 504 определяют однонаправленный канал по умолчанию EPS на основании определения первичного контекста PDP, принятого с помощью команды АТ. Так как всегда имеется один однонаправленный канал по умолчанию EPS на соединение PDN, первичный контекст PDP также будет задавать соединение PDN, которое принадлежит однонаправленному каналу по умолчанию EPS. Как упомянуто выше, каждое соединение PDN имеет свой собственный адрес IP.

В принятой команде АТ +CGDCONT первичный контекст, определенный в ней, связан с конкретным параметром CID, также включенным в эту команду АТ. Первичный контекст PDP, определенный для этого параметра CID, не будет включать в себя все услуги в однонаправленном канале по умолчанию EPS, так как он будет использован только в качестве ссылки на конкретную услугу по умолчанию/соединение по умолчанию в этом однонаправленном канале по умолчанию EPS, связанном с универсальными пакетными фильтрами восходящей линии связи и нисходящей линии связи (т.е. в качестве ссылки на услугу по умолчанию/соединение по умолчанию, для которого не определены выделенные пакетные фильтры, например, в соответствии с SDF). Это означает, что первичный контекст PDP, определенный для конкретного параметра CID (а также сам конкретный параметр CID), не будет использован в качестве ссылки на любые (другие) SDF в конкретном однонаправленном канале по умолчанию EPS, так как на эти CID можно ссылаться с помощью других параметров CID, как будет обсуждено более подробно ниже.

После этапа 504 определения однонаправленного канала по умолчанию EPS работа интерфейса 80 команд АТ продолжается со ссылкой на вновь определенный однонаправленный канал по умолчанию EPS с помощью конкретного параметра CID, включенного в соответствующую команду АТ +CGDCONT, с помощью компонента 92 ссылки CID (этап 506). С этой целью конкретный параметр CID вводят вместе с идентификатором вновь определенного однонаправленного канала по умолчанию EPS (соответствующего, например NSAPI в сценарии пакетного домена GPRS) в таблицу, сохраненную в памяти 94.

На следующем этапе 508 генерируют запрос активации вновь определенного однонаправленного канала по умолчанию EPS. Этап 508 может быть выполнен с помощью компонента 88 обработки команд АТ в ответ на прием команды АТ +CGACT с помощью интерпретатора 82. Чтобы идентифицировать однонаправленный канал по умолчанию EPS, который должен быть активирован, компонент 88 обработки команд АТ может определить параметр CID, включенный в команду АТ +CGACT, и извлечь связанный идентификатор однонаправленного канала по умолчанию EPS из памяти 94, как проиллюстрировано с помощью стрелки на фиг.4. Еще на этапе 508 компонент 88 обработки команд АТ может сгенерировать запрос возможности соединения PDN для конкретного однонаправленного канала по умолчанию EPS и передать запрос с помощью управляющей сигнализации МТ в МТ 70 фиг.3. Затем МТ 70 фиг.3 передаст этот запрос с помощью соответствующего сообщения сети в пакетный домен 30 EPS.

Теперь вторая ветвь обработки блок-схемы 500 последовательности этапов, проиллюстрированной на фиг.5, будет рассмотрена более подробно. Вторая ветвь обработки начинается на этапе 510 с определением SDF EPS на основании параметров вторичного контекста PDP, включенных в сообщение АТ +CGDSCONT, принятое на этапе 502. Этап 510 выполняют с помощью компонента 84 определения SDF EPS, который определяет на основании вторичного контекста PDP, принятого с командой АТ +CGDSCONT, новый SDF EPS в существующем соединении PDN. Это означает, что вновь определенный SDF основан на тех же установках протокола IP, что и однонаправленный канал по умолчанию EPS, связанный с вновь определенным SDF. Приложение 22 не уведомляют о том, будет ли установлен вновь определенный SDF в новом выделенном однонаправленном канале EPS, в уже существующем выделенном однонаправленном канале EPS или в связанном однонаправленном канале по умолчанию EPS. Вновь определенный SDF будет связан с конкретным соединением PDN с помощью задания параметра CID связанного однонаправленного канала по умолчанию EPS (например, в памяти 94).

Если SDF EPS определен на этапе 510, работа интерфейса 80 команд АТ продолжается с этапом 512. На этапе 512 на вновь определенный SDF EPS ссылаются с помощью параметра CID, также транспортированного в команде АТ +CGDSCONT, которая включала в себя вторичный контекст PDP, определяющий SDF EPS. С этой целью компонент 90 ссылки CID генерирует новую запись в таблице в памяти 94. Эта новая запись связывает параметр CID с идентификатором вновь сгенерированного SDF. Кроме того, запись таблицы может включать в себя параметр CID однонаправленного канала по умолчанию EPS, лежащего в основе вновь определенного SDF.

На дополнительном этапе 514 генерируют запрос активации вновь определенного SDF. Как уже обсуждено выше со ссылкой на этап 508, запрос активации SDF может быть сгенерирован в ответ на прием команды АТ +CGACT, запрашивающей активацию конкретного вторичного контекста PDP. Компонент 88 обработки команд АТ затем на первом этапе определит параметр CID, включенный в эту команду +CGACT, извлечет связанный идентификатор SDF (и выборочно соответствующий идентификатор связанного однонаправленного канала по умолчанию EPS) из таблицы в памяти 94 и сгенерирует запрос назначения ресурсов однонаправленного канала или подобное сообщение, посылаемое с помощью МТ 70 в пакетный домен 30 EPS.

Как стало понятным из вышеописанного, будут определены различные идентификаторы, считываемые и обрабатываемые с помощью интерфейса 80 команд АТ во время его работы. Все эти идентификаторы могут быть сохранены в таблице (или любой другой структуре данных) в памяти 94. Обычно идентификаторы по отношению к сети (пакетному домену GPRS или пакетному домену EPS) будут отличаться от идентификаторов, используемых по отношению к приложению 22. Таблица 600 на фиг.6 иллюстрирует зависимость между идентификаторами по отношению к сети и идентификаторами по отношению к приложению 22 для пакетного домена GPRS и пакетного домена EPS, соответственно.

Информация, сохраненная в памяти 94, также может быть использована в контексте передачи обслуживания или изменения RAT (например, от доступа к сети WCDMA к доступу к сети LTE или наоборот). Главной целью является то, что интерфейс 80 команд АТ не должен требовать адаптации по отношению к приложению 22 в случае передачи обслуживания или изменения RAT. Иначе говоря, желательно, чтобы приложение 20 могло оставаться агностическим от конкретной активной в текущий момент RAT.

На обеих сторонах интерфейса 80 команд АТ, т.е. по отношению к сети и по отношению к приложению 22, в режиме существующей UMTS (включая, например, WCDMA, GPRS или EDGE) контексты PDP используют для управления однонаправленным каналом и соединением IP и их назначения. Из-за этой причины имеется зависимость один к одному между параметрами CID и параметрами NSAPI в традиционных решениях интерфейса. Эта зависимость один к одному на обеих сторонах интерфейса 80 команд AT должна быть изменена, для того чтобы обрабатывать передачу обслуживания от доступа к сети LTE к доступу к сети существующей UMTS, таким образом, чтобы существовала зависимость один к одному между контекстами PDP по отношению к сети (идентифицированной с помощью параметров NSAPI) и контекстами PDP по отношению к приложению 22 (идентифицированному с помощью параметров CID).

Эта зависимость один к одному означает, что, если имеются n SDF, отображенных в один однонаправленный канал EPS до передачи обслуживания или изменения RAT, будет n контекстов PDP в интерфейсе по отношению к приложению 22, которое отображают в один контекст PDP в интерфейсе по отношению к сети (т.е. по отношению к пакетному домену GPRS после передачи обслуживания или изменения RAT). Это отображение может быть выполнено с помощью выделенного компонента (не изображен) интерфейса 80 команд АТ на основании записей таблицы в памяти 94.

До сих пор описание вариантов осуществления было сфокусировано на командах АТ +CGDCONT и +CGDSCONT и на некоторых аспектах команды АТ +CGACT. В дальнейшем будет описана работа интерфейса 80 команд АТ и, более конкретно его компонента 88 обработки команд АТ для других существующих команд АТ, поддерживаемых с помощью контроллера 24 команд АТ.

Во-первых, контроллер 24 команд АТ может поддерживать команду АТ +CGEQREQ. Эта команда позволяет ТЕ 50 (и приложению 22) задавать профиль QoS, который используют, когда UE 20 намеревается назначить ресурсы однонаправленного канала (например, с помощью посылки сообщения запроса назначения ресурсов однонаправленного канала в сеть). В сценарии пакетного домена EPS команда задает профиль QoS для SDF, идентифицированного с помощью параметра CID, включенного в команду. Для обратной совместимости сама команда задает профиль QoS в соответствии с редакцией 7 спецификаций 3GPP. Следовательно, для того чтобы осуществить профиль QoS в пакетном домене EPS, интерфейс команд АТ может осуществлять логическую схему преобразования, которая преобразует запрошенный профиль QoS редакции 7 3GPP в профиль QoS редакции 8 3GPP для пакетного домена EPS.

Интерфейс 80 команд АТ может дополнительно поддерживать команду АТ +CGEQMIN. Эта команда позволяет TE 50 и приложению 22 задавать минимальный допустимый профиль QoS, который проверяют с помощью UE 20 относительно согласованного профиля QoS, как возвращенного, например, в сообщении запроса активации контекста выделенного однонаправленного канала или запроса модификации контекста однонаправленного канала EPS. Команда задает профиль QoS для SDF, идентифицированного с помощью CID, включенного в команду. Для обратной совместимости сам профиль QoS задают в соответствии с редакцией 7 3GPP. Следовательно, для того чтобы использовать запрошенный профиль QoS редакции 7 3GPP в пакетном домене EPS, интерфейс 80 команд АТ должен осуществить логическую схему преобразования, которая преобразует запрошенный профиль QoS редакции 7 3GPP в профиль QoS редакции 8 3GPP для пакетного домена EPS.

Еще одной дополнительной командой АТ, поддерживаемой с помощью интерфейса 80 команд АТ, может быть +CGEQNEG. Эта команда позволяет TE 50 и приложению 22 извлекать согласованный профиль QoS на SDF (как идентифицированный с помощью параметра CID, включенного в команду АТ), возвращенный в сообщение запроса активации контекста выделенного однонаправленного канала или запроса модификации контекста однонаправленного канала EPS. Независимо от наличия только одного определения QoS на однонаправленный канал EPS в сети (а не на SDF), команды АТ для определения профиля QoS могут быть повторно использованы для пакетного домена EPS. Следовательно, на стороне UE может быть обеспечено расширение, которое позволяет сохранение (например, в памяти 94) согласованного профиля QoS, возвращенного на SDF. Следует заметить, что для пакетного домена GPRS профиль QoS должен быть сохранен только на контекст PDP, так как один параметр CID относится точно к одному контексту PDP. Также следует заметить, что согласованный профиль QoS в системе LTE предполагают как одинаковый для всех SDF в одном и том же однонаправленном канале EPS.

Интерфейс 80 может дополнительно поддерживать команду АТ +CGTFT. Эта команда дает возможность приложению 22 определять, по меньшей мере, один пакетный фильтр, который назначают в SDF. Сам SDF может относиться к множеству из одного или нескольких пакетных фильтров. В системе LTE один или более пакетных фильтров (соответствующих TFT в системе существующей UMTS) определяют для соединения PDN и определяют правила относительно того, как маршрутизировать пакеты в выделенные однонаправленные каналы EPS, доступные в соединении PDN. В настоящем случае не будет иметь значения, что параметры CID не идентифицируют выделенные каналы EPS, но вместо них SDF. В пакетном домене GPRS команда АТ +CGTFT требует сохранения данных отслеживания всех пакетных фильтров, которые определены для данного адреса IP. В этом контексте идентификаторы пакетных фильтров должны быть уникальными относительно всех параметров CID, связанных с параметром CID первичного контекста PDP. Поскольку определения пакетных фильтров могут быть выполнены для любого параметра CID, но должны быть отслежены по всему вторичному контексту PDP в соединении PDN, это не будет вызывать никаких проблем, если параметры CID используют, чтобы обозначать SDF в системе LTE. Однако все же необходимо отслеживать идентификаторы пакетных фильтров, чтобы убедиться, что все идентификаторы пакетных фильтров являются уникальными по всем SDF, принадлежащим одному соединению PDN.

Как уже кратко упомянуто выше, интерфейс 80 команд АТ также поддерживает команду АТ +CGACT. Эту команду «выполнения» используют, чтобы активировать или деактивировать однонаправленные каналы EPS и/или SDF. Однонаправленные каналы EPS и SDF задают в команде АТ CGACT с помощью их соответственного параметра QoS. Кроме использования случаев для активации однонаправленного канала по умолчанию EPS или SDF, обсужденных выше со ссылкой на фиг.5, также могут быть осуществлены сценарии деактивации. Например, в случае, когда запрашивают, чтобы был деактивирован однонаправленный канал по умолчанию EPS, запрос разъединения SDF может быть послан в сеть. С другой стороны, если запрашивают, чтобы был деактивирован SDF, соответствующее сообщение освобождения (такое как сообщение запроса освобождения ресурсов однонаправленного канала) будет послано в сеть.

Еще, кроме того, интерфейс 80 команд АТ также может поддерживать команду АТ +CGCMOD. Эту команду используют, чтобы модифицировать SDF, заданный с помощью конкретного параметра CID в команде. Модификация может, в частности, относиться к профилям QoS и пакетным фильтрам. Для каждого модифицируемого SDF соответствующее сообщение модификации (такое как сообщение запроса назначения ресурсов однонаправленного канала) будет послано в сеть.

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

Так как параметры профилей QoS редакции 8 3GPP отличаются от параметров профилей QoS редакции 7 3GPP, должны бы быть введены новые команды АТ для запрошенных профилей QoS LTE, минимального профиля QoS LTE и согласованного профиля QoS LTE. В основном существуют два способа, как включить эти новые команды в существующее множество команд.

Первым вариантом является замена команд АТ профиля QoS редакции 7 3GPP на новые команды АТ. Иначе говоря, новые команды заменили бы старые команды как для UE с одной RAT LTE, так и для UE с множеством RAT, поддерживающего, например, доступ к сети LTE и доступ к сети WCDMA. Следовательно, UE с множеством RAT должно обеспечивать логическую схему преобразования, которая преобразует запрошенный профиль QoS редакции 8 3GPP в профиль QoS редакции 7 3GPP, в случае когда WCDMA является активной RAT.

Вторым вариантом было бы совместное существование новых команд АТ с существующими командами АТ. В случае, когда приложение определяет или запрашивает профиль QoS с помощью существующей команды АТ, UE запрашивает логическую схему преобразования, которая преобразует команду АТ редакции 7 3GPP в команду АТ редакции 8 3GPP, когда LTE является активной RAT. Преобразование должно быть выполнено в другом направлении в случае, когда приложение определяет или запрашивает профиль QoS с помощью вновь введенной команды АТ, в то время как WCDMA или другая RAT существующей UMTS (включая, например, WCDMA, GPRS и EDGE) является активной. В случае, когда приложение определяет или запрашивает две версии профиля QoS, соответствующие традиционной команде АТ и вновь определенной команде АТ, UE может использовать параметры традиционной команды АТ для доступа к сети существующей UMTS (включая, например, GPRS и EDGE), а параметры вновь определенной команды АТ для доступа к сети LTE.

Дополнительно обнаружено, что современные множества команд АТ не поддерживают удаление пакетного фильтра для SDF, что могло бы быть полезным, в частности, для услуг LTE. В основном имеются следующие возможности, чтобы ввести новые функциональные возможности. Во-первых, команда АТ +CGTFT могла бы быть расширена. Например, могло бы быть определено конкретное расширение команды АТ +CGTFT, которая вызывает освобождение одного или более пакетных фильтров, идентифицированных в команде, из конкретного SDF, также идентифицированного в команде (например, с помощью связанного параметра CID). В соответствии с дополнительным вариантом может быть введена новая команда АТ для удаления пакетного фильтра. Эта команда может содержать параметры для идентификации одного или более удаляемых пакетных фильтров, а также дополнительные параметры (такие как параметры CID), идентифицирующие конкретный SDF, к которому применяется команда.

Как стало понятно из вышеописанных вариантов осуществления, метод, описанный в настоящей заявке, имеет различные выгодные результаты. Например, метод позволяет обеспечение общего интерфейса по отношению к приложениям для управления однонаправленным каналом и соединением IP и их назначения, который является независимым от активной в текущий момент RAT (такой как GPRS, EDGE, WCDMA eHSPA и LTE). В результате услуги пакетного домена EPS могут быть предоставлены в существующие приложения и пользовательские интерфейсы без требования какой-либо адаптации. В частности, приложения, соответствующие пакетному домену GPRS, могут получать пользу от услуг пакетного домена EPS без необходимости адаптировать приложения.

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

Заявленное изобретение относится к методу способствования использованию команд АТ, заданных для пакетного домена универсальной пакетной радиослужбы (GPRS), в связи с пакетным доменом развитой пакетной системы (EPS). Технический результат состоит в эффективности поддержки пакетного домена EPS. Для этого вариант осуществления способа этого метода содержит определение, в ответ на команду АТ, направленную на определение вторичного контекста протокола пакетных данных (PDP), сервисного потока данных EPS (SDF) на основании вторичного контекста PDP. 4 н. и 12 з.п. ф-лы, 6 ил.

1. Способ способствования использованию команд AT, заданных для пакетного домена универсальной пакетной радиослужбы (GPRS) в связи с пакетным доменом развитой пакетной системы (EPS), причем способ содержит:
прием команды AT посредством интерфейса (80) команд AT контроллера (24) команд AT в пользовательском оборудовании (20), причем упомянутая команда AT включает в себя параметр идентификации контекста (CID) в качестве ссылки на контекст протокола пакетных данных (PDP),
характеризующийся наличием этапов, на которых:
в ответ на команду AT, направленную на определение вторичного контекста PDP в существующем соединении сети пакетных данных (PDN):
определяют сервисный поток данных EPS (SDF EPS) на основании вторичного контекста PDP,
используют параметр CID, включенный в команду AT в качестве ссылки на SDF EPS, и однонаправленный канал по умолчанию EPS, связанный с SDF EPS, чтобы связывать SDF EPS с соединением PDN, связанным с однонаправленным каналом по умолчанию EPS,
в ответ на команду AT, направленную на определение не вторичного PDP,
определяют однонаправленный канал по умолчанию EPS на основании не вторичного контекста PDP;
используют параметр CID, включенный в команду AT, в качестве ссылки на однонаправленный канал по умолчанию EPS;
сохраняют параметр CID и связанный идентификатор SDF EPS и однонаправленного канала по умолчанию EPS.

2. Способ по п.1, в котором интерфейс (80) команд содержит механизм для определения выделенного однонаправленного канала EPS, и дополнительно характеризуется наличием этапов, на которых:
определяют выделенный однонаправленный канал EPS в ответ на команду AT, включающую в себя параметр идентификации контекста (CID), и
используют параметр CID, включенный в команду AT, в качестве ссылки на выделенный однонаправленный канал EPS.

3. Способ по п.1 или 2, причем способ выполняют с помощью режима долгосрочного развития (LTE) пользовательского терминала, дополнительно поддерживающего режим существующей UMTS и в котором пользовательский терминал может выполнять, по меньшей мере, одно из:
передачи обслуживания и изменения технологии радиодоступа (RAT), между доступом к сети LTE и доступом к сети существующей UMTS, и дополнительно характеризуется наличием этапов, на которых:
при нахождении в режиме существующей UMTS, интерпретируют каждую команду AT способом, заданным для пакетного домена GPRS,
при передаче обслуживания или изменении RAT, в котором определены n контекстов PDP, и n SDF EPS связаны с одним однонаправленным каналом EPS в пакетном домене EPS до передачи обслуживания, отображают n контекстов PDP на один контекст PDP по отношению к пакетному домену GPRS.

4. Способ по п.1 или 2, в котором интерфейс (80) команд содержит логическую схему преобразования между профилями качества обслуживания (QoS) GPRS и профилями QoS EPS, причем логическую схему преобразования используют в ответ на команду AT, задающую профиль QoS, причем команда AT является любой из команд AT: +CGEQREQ (установить запрошенное QoS), +CGEQMIN (минимальное QoS), +CGEQOS (определить QoS) и +CGEQOSRDP (считывать динамические параметры QoS) и при этом профили QoS GPRS являются совместимыми с профилем QoS редакции 7 3GPP или более ранним профилем QoS, а профили QoS EPS являются совместимыми с профилем QoS редакции 8 3GPP или более поздним профилем QoS.

5. Способ по п.1 или 2, дополнительно характеризующийся наличием этапов, на которых:
обеспечивают поддержку для, по меньшей мере, одной из команды AT+CGCMOD (изменить контекст PDP) и команды AT+CGTFT (определить шаблон потока трафика),
обеспечивают поддержку для команды AT+CGACT (активировать/деактивировать контекст PDP), содержащей инструкции, согласно которым:
посылают сообщение, относящееся к активации ресурса однонаправленного канала, после активации SDF EPS; или
посылают сообщение, относящееся к освобождению ресурса однонаправленного канала, после деактивации SDF EPS; или
посылают сообщение запроса возможности соединения с PDN после активации однонаправленного канала по умолчанию EPS; или
посылают сообщение запроса отключения от PDN после деактивации однонаправленного канала по умолчанию EPS.

6. Способ по п.1 или 2, в котором команду AT принимают из приложения, запрашивают или инициируют с помощью приложения, в котором приложение является агностическим от того, существует ли соединение с пакетным доменом GPRS или пакетным доменом EPS, или приложение сконфигурировано с возможностью выделенной обработки выделенных однонаправленных каналов EPS.

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

8. Устройство (80) для способствования использованию команд AT, заданных для пакетного домена универсальной пакетной радиослужбы (GPRS), в связи с пакетным доменом развитой пакетной системы (EPS), причем устройство характеризуется тем, что содержит:
компонент (84), выполненный с возможностью определять, в ответ на команду AT, направленную на определение вторичного контекста протокола пакетных данных, или PDP, сервисный поток данных EPS, или SDF, на основании вторичного контекста PDP.

9. Устройство по п.8, в котором SDF EPS определяют в существующем соединении сети пакетных данных, или PDN.

10. Устройство по п.8 или 9, в котором каждая команда AT включает в себя параметр идентификации контекста, или CID, в качестве ссылки на контекст PDP.

11. Устройство по п.8 или 9, дополнительно содержащее
компонент (90), выполненный с возможностью использовать параметр CID, включенный в команду AT, в качестве ссылки на SDF EPS.

12. Устройство по п.8, дополнительно содержащее
компонент (86), выполненный с возможностью определять в ответ на команду AT, направленную на определение не вторичного контекста PDP, однонаправленный канал по умолчанию EPS на основании не вторичного контекста PDP.

13. Устройство по п.12, дополнительно содержащее
компонент (92), выполненный с возможностью использовать параметр CID, включенный в команду AT, в качестве ссылки на однонаправленный канал по умолчанию EPS.

14. Устройство по п.13, дополнительно содержащее
компонент (92), выполненный с возможностью использовать параметр CID, включенный в команду AT, в качестве связи с соединением сети пакетных данных, или PDN, связанным с однонаправленным каналом по умолчанию EPS.

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

16. Пользовательский терминал, содержащий устройство по любому из п.8-15.