Формат tap файла с gprs
Transferred Account Procedure is the mechanism by which wireless operators exchange roaming billing information. The GSM Association in 1995 released the very first TAP specification, i.e., TAP version 1. From then onward, the specifications have continuously evolved to support new services and associated operational aspects. For example, in the earlier versions, the usage was recorded in terms of call detailed records (CDRs). This was changed to call event detail (CED) to reflect the nature of services in current and future generations of networks. TAP2 and TAP2+ were introduced later; they allowed the operators to bill for new services and provide the additional information required by satellite and U.S. operators. TAP3 is the latest version released by the GSM Association. It includes all the features supported by earlier versions of TAP. In addition, it supports billing for new-generation services, including mobile multimedia and prepaid roaming. It also supports interoper-ator tariff (IOT) charging principles and key information for marketing and customer service functions.
TAP3 and earlier versions
The latest version, TAP3, is designed to cater to the needs of the next-generation services. It uses an industry-standard coding scheme, i.e., ASN.1. This enables use of commercially available tools rather than proprietary toolkits. Many of the earlier version constraints, e.g., file size limitation, have been also removed.
■ High-speed circuit-switched (HSCSD) and packet-switched (GPRS) data services
■ Prepaid roaming using CAMEL
■ USSD charging
■ Mobile directory number to support mobile number portability for interstandard roaming
■ Support of private numbering plans (SPNP)
■ Enhanced full rate (EFR) for enhanced voice quality
■ Fraud information gathering system (FIGS), including fraud monitoring indicator and third-party number
■ Support for UMTS QoS
■ HPLMN repricing—enables HPLMN to reprice each call according to its own tariff plan
■ Call-level discounts
TAP3 also allows for the specific requirements of satellite networks and of large countries where no single operator covers the entire geographic area. This includes support for the following additional parameters.
■ Additional charging parameters, e.g., separation of airtime and toll charges
■ Additional time zones
Unlike earlier versions, TAP3 also contains valuable information about roamer and also services used by a roamer. Wireless service providers can use this information for marketing (e.g., targeted campaigns) and customer care. This information could also be used to build roamer profiles and ad hoc studies as and when required. This enables various stakeholders within a roaming organization to make informed business decisions.
TAP-in and TAP-out processes
In the GSM world, the usage records are generated in mobile switching centers (MSCs), short message service centers (SMSCs), and voice mail service centers (VMSCs). Several different types of records are generated, depending on the usage. For example, call detailed records (CDRs) for mobile-originated (MO) and mobile-terminating (MT) calls, transaction detailed records for MO-SMS, MT-SMS, and other nonvoice usage. In GPRS and 3G, usage records are generated at the SGSNs, GGSNs, MMSCs, and a host of other gateway elements. The usage records are generated for packet-switched data calls, MMS, and access of contents.
The TAP-out process enables an HPMN (the PLMN where TAP-out processing is performed) to send rated records for the calls made by inbound roamers (visitors from foreign networks) to their respective home networks (VPMNs).
As shown in Figure 11-2, the serving MSC in the visited network creates detailed records every time a roamer successfully accesses a service. These records are then transferred to the billing system for rating and pricing. The billing system segregates and group calls/records created for the roamers and converts those in the ASN.1 TAP file format. The MCC and MNC codes in IMSIs are used to validate and group the calls. The TAP files contain rated call information. The rating is done in accordance with the bilateral agreement between operators. These TAP files are then sent to roaming partners on a regular basis. This transfer takes place either directly or via a clearinghouse. The frequency of transfer is subject to the bilateral roaming agreement and generally decided up-front. In general, the TAP file exchange should take place as frequently as possible to enable monitoring of high usage and possible fraud.
Electronic data interchange (EDI) is the standard mechanism of TAP file transfer to ensure that charging records are made available to the HPLMN without delay. In case of EDI failure, magnetic tapes or some other suitable mechanism can be used as a fallback and are subject to a bilateral agreement. Magnetic tape technology is fast becoming obsolete.
The TAP-in process at the receiving network accepts the files generated by its partner networks. The TAP-in process involves parsing, validation, conversion of usage data into internal format, and prerating in accordance with the roaming tariff plan. The reject and return process is used in the cases where the validation of TAP files results in errors.
Reject and return process
A new procedure called reject and return was introduced recently as part of the TAP3 specification in order to handle errors in TAP files efficiently. Before the implementation of this process, an error concerning one single call in a TAP file resulted in rejection of the entire file. This was the cause of unnecessary delays in the billing and settlement process.
Figure 11-2 Transferred account procedure.
The reject and return process allows processing of validated CEDs to proceed and return of errored CEDs back to the concerned VPMN. An automated mechanism can be built to handle the fatal errors and missing files or data. Having fewer call event details at the end of the month in the reclaims process allows an early interoperator settlement.
Having the capability to reject individual call event details also benefits the retail billing process and early realization of dues from subscribers. Figure 11-3 describes a simplified view of TAP file transfer using the rejects and returns process.
■ TAP file validation
■ Missing file detection
■ Fatal error detection
■ Severe error detection
■ Creation of a RAP file
■ Transmission of RAP files to the concerned VPLMN
Роуминг – это возможность для клиента мобильной связи автоматически совершать и принимать телефонные звонки, отправлять и получать данные или получать доступ к другим услугам во время поездки за пределы географической зоны действия домашней сети посредством использования сети другого оператора.
Роуминг может быть как в национальном, так и в международном роуминге. Национальный роуминг означает, что мобильные абоненты используют другую сеть в географических зонах, где их собственный оператор не имеет покрытия. Это, например, используется операторами, которые не имеют полного покрытия в стране. Международный роуминг используется, когда мобильные абоненты выезжают за границу и используют сеть оператора в чужой стране.
Как это на самом деле происходит? Если у поставщика услуг нет покрытия сети в определенном городе или стране, то этот поставщик услуг заключает соглашение о роуминге с другим поставщиком услуг, имеющим сеть в этом городе или стране. Согласно этому соглашению, другой поставщик услуг предоставляет все доступные услуги роуминговому клиенту первого поставщика услуг.
CDR, сгенерированные в зоне одного партнера по роумингу, собираются и оцениваются этим партнером по роумингу и, наконец, отправляются фактическому поставщику услуг клиента в роуминге. Фактический поставщик услуг взимает с конечного клиента все услуги роуминга, основанные на их заранее определенных тарифах на обслуживание.
Два роуминговых партнера ежемесячно рассчитывают свои финансовые показатели путем обмена фактическими CDR в роуминге и отчетами на основе этих CDR.
HPMN и VPMN
Посещаемая общедоступная мобильная сеть – это сеть, используемая мобильным абонентом в роуминге. Этот термин используется в отличие от домашней публичной мобильной сети (HPMN).
Клиринговый Дом
Есть хорошо известные организации, такие как MACH, которые взаимодействуют между различными партнерами по роумингу, чтобы помочь им обмениваться своими CDR, устанавливать соглашения о роуминге и разрешать любые споры.
Клиринговые центры получают платежные записи от одного роумингового партнера для входящих роумеров и представляют платежные записи другому роуминговому партнеру, для которого этот роумер будет называться исходящим роумиром.
Что такое TAP3?
Процедура переносимой учетной записи версии 3 (TAP3) – это процесс, который позволяет посещаемому оператору сети (VPMN) отправлять платежные записи абонентов роуминга их соответствующему оператору домашней сети (HPMN). TAP3 является последней версией стандарта и позволит выставлять счета за множество новых услуг, которые сети намерены предложить своим клиентам.
Центр обмена информацией использует протокол TAP3 для обмена всеми CDR между различными партнерами по роумингу. TAP3 определяет, как и какая информация об использовании в роуминге должна передаваться между операторами сети. Эти файлы обмениваются с помощью простого FTP-соединения.
Существуют разные версии TAP. TAP эволюционировал от TAP1 до TAP2 и от TAP2 + до TAP3. Последний выпуск, TAP3, включает поддержку межстандартного роуминга в спутниковой сети, WLAN и UMTS и других технологий 3G.
Стандарт GSM TAP TD.57 – Процедура передачи учетных записей GSM (TAP) определяет формат и правила проверки для передачи информации об использовании роуминга между операторами мобильной связи в разных странах. TAP3 является третьей версией спецификации стандарта. Переданные файлы называются файлами TAP.
Стандарт GSM RAP TD.32 – Процедура возврата учетных записей GSM (RAP) определяет формат для возврата информации об ошибках, обнаруженных в переданных файлах / событиях TAP, и, таким образом, отклонения финансовой ответственности за эти файлы / события. Переданные файлы называются файлами RAP.
Стандарт GSM TAP TD.57 – Процедура передачи учетных записей GSM (TAP) определяет формат и правила проверки для передачи информации об использовании роуминга между операторами мобильной связи в разных странах. TAP3 является третьей версией спецификации стандарта. Переданные файлы называются файлами TAP.
Стандарт GSM RAP TD.32 – Процедура возврата учетных записей GSM (RAP) определяет формат для возврата информации об ошибках, обнаруженных в переданных файлах / событиях TAP, и, таким образом, отклонения финансовой ответственности за эти файлы / события. Переданные файлы называются файлами RAP.
Роуминг Биллинг
Мобильный абонент путешествует в другую страну и создает использование во внешней сети. Чтобы выставить счет абоненту, эта информация должна быть передана обратно в домашнюю сеть абонента. Внешняя сеть будет собирать информацию об использовании с ее коммутаторов и т. Д., А затем создает файлы TAP, содержащие информацию, изложенную в стандарте.
Затем файлы экспортируются (на регулярной основе, как правило, по крайней мере, по одному файлу в день) оператору дома, который их ИМПОРТИТ, а затем использует эту информацию для выставления счета подписчику. Иностранный оператор будет оценивать звонки, а затем взимать плату с домашней сети абонентов за все звонки в файле. Домашний оператор может пометить или повторно оценить звонки, чтобы получить доход.
Формат файла tap zx spectrum
The .TAP files contain blocks of tape-saved data. All blocks start with two bytes specifying how many bytes will follow (not counting the two length bytes). Then raw tape data follows, including the flag and checksum bytes. The checksum is the bitwise XOR of all bytes including the flag byte. For example, when you execute the line SAVE "ROM" CODE 0,2 this will result:
13 00 00 03 52 4f 4d 7x20 02 00 00 00 00 80 f1 04 00 ff f3 af a3
^^^^^. first block is 19 bytes (17 bytes+flag+checksum)
^^. flag byte (A reg, 00 for headers, ff for data blocks)
^^ first byte of header, indicating a code block
file name ..^^^^^^^^^^^^^
header info . ^^^^^^^^^^^^^^^^^
checksum of header . ^^
length of second block . ^^^^^
flag byte . ^^
first two bytes of rom . ^^^^^
checksum (checkbittoggle would be a better name!). ^^
Note that it is possible to join .TAP files by simply stringing them together; for example, in DOS / Windows: COPY /B FILE1.TAP + FILE2.TAP ALL.TAP ; or in Unix/Linux: cp file1.tap all.tap && cat file2.tap >> all.tap
For completeness, I'll include the structure of a tape header. A header always consists of 17 bytes:
Byte Length Description
0 1 Type (0,1,2 or 3)
1 10 Filename (padded with blanks)
11 2 Length of data block
13 2 Parameter 1
15 2 Parameter 2
The type is 0,1,2 or 3 for a Program, Number array, Character array or Code file. A SCREEN$ file is regarded as a Code file with start address 16384 and length 6912 decimal. If the file is a Program file, parameter 1 holds the autostart line number (or a number >=32768 if no LINE parameter was given) and parameter 2 holds the start of the variable area relative to the start of the program. If it's a Code file, parameter 1 holds the start of the code block when saved, and parameter 2 holds 32768. For data files finally, the byte at position 14 decimal holds the variable name.
Вопрос по блокам
length of second block . ^^^^^
flag byte . ^^
first two bytes of rom . ^^^^^
checksum (checkbittoggle would be a better name!). ^^
что это за блок и откуда берутся first two bytes of rom (в каждом файле они разные)
Нужно ли этот блок считывать.
На самом деле, формат файла .TAP очень простой. Формат предназначен для хранения данных, записанных на кассете магнитофона на стандартной скорости записи, без информации о паузах и т.п.
Каждый блок данных предваряется двумя байтами его длины, и дальше идут собственно данные. Это всё.
2 байта длины (младший вначале), затем данные блока последовательно, начиная с первого флагового байта, заканчивая последним байтом контрольной суммы.
Собственно, формат о них ничего не знает, и первый и последний байт могут быть произвольными, но для корректной загрузки стандартными загрузчиками обычно первый байт - флаговый, последний - байт контрольной суммы (XOR всех предыдущих байтов блока).
Формат стандартного заголовочного блока Бейсика такой:
1 байт - флаговый, для блока заголовка всегда равен 0 (для блока данных за ним равен 255)
1 байт - тип Бейсик блока, 0 - бейсик программа, 1 - числовой массив, 2 - символьный массив, 3 - кодовый блок
10 байт - имя блока
2 байта - длина блока данных, следующего за заголовком (без флагового байта и байта контрольной суммы)
2 байта - Параметр 1, для Бейсик-программы - номер стартовой строки Бейсик-программы, заданный параметром LINE (или число >=32768, если стартовая строка не была задана. Для кодового блока - начальный адрес блока в памяти. Для массивов данных - 14й-байт хранит односимвольное имя массива
2 байта - Параметр 2. Для Бейсик-программы - хранит размер собственно Бейсик-програмы, без инициализированных переменных, хранящихся в памяти на момент записи Бейсик-программы. Для остальных блоков содержимое этого параметра не значимо, и я почти уверен, что это не два байта ПЗУ. Скорее всего, они просто не инициализируются при записи.
1 байт - контрольная сумма заголовочного блока.
Считывать блок заголовка нужно, если программа не знает точных параметров блока данных за ним. Если знает, его можно пропустить.
Понял, откуда 2 байта ПЗУ. В примере описано содержимое файла .TAP, для сохраненного из Бейсика командой
блока кодов ПЗУ длиной 2 байта. Это актуально только для данного примера:
Вот я писал модуль для работы с форматом tap, в нём реализован базис, включая подсчёт контрольной суммы.
P.S. Сорри за Оберон. Любителей его поругать просьба идти.
Благодарю за поддержку, буду реализовывать для STM32 в среде ARM Keil. Там язык C.
Пока разбираюсь с таймерами и прерываниями.
Нужно реализовать пилот тон и синхо.
Всем добра.
Подскажите правильно я делаю или нет.
Алгоритм чтения tap файла
1. Сначала пилот для заголовка длительность 5 сек. частота 807 Гц
2. Синхроимпульс ~ 171,4 мксек
3. Синхроимпульс 200 мксек
4. Читаем 17 байт заголовка
где
00. 01 это длина заголовка (обычно 0х13)
02 флаг 00 для заголовка FF для блока данных
04. 0D имя файла
15..16 длина блока данных
17 флаг FF
5. Пилот тон данных 2 сек. 807Гц
6. Синхроимпульс ~ 171,4 мксек
7. Синхроимпульс 200 мксек
8. Чтение блока данных
Нет, не правильно. Заголовок это флаговый байт 00 + 17 байт заголовка + байт контрольной суммы, итого 19 байт. (Но при загрузке заголовка мы задаем загрузчику длину 17, потому что флаговый байт и байт контрольной суммы служебные, и не учитываются.)
Длина заголовка в заголовке не хранится, потому что она фиксирована. Она хранится только в TAP файле, потому что он ничего не знает о содержимом блоков, он хранит только их длины+содержимое.
Так что:
пилот
синхро1
синхро2
флаговый байт 00
байт типа даннных (03 - для кодового блока)
10 байт имени
2 байта длины блока кодов
2 байта ещё один параметр (стартовый адрес для кодового блока)
2 байта ещё один параметр (незначим для кодового блока)
1 байт контрольной суммы
пауза
пилот
синхро1
синхро2
флаговый байт FF
содержимое блока кодов длиной, указанной в заголовке
байт контрольной суммы
пауза
Всегда возникает много вопросов как происходит расчет стоимости услуг связи в роуминге. Специалистов по роумингу мало, и как правило им не до написания статей. Попробую кратко описать возможные варианты, технологии и обозначу проблемы.
Классификация и определения.
- Въездной (inbound). В случае въездного роуминга счет выставляется оператору, чьи абоненты приехали в сеть.
- Выездной (outbound). А в этом случае оператор выставляет счет своим абонентам, и сам получает счет от оператора, в сети которого регистрируются абоненты.
- Абонент воспользовался услугой;
- Оператор из CDR выбрал записи гостей и сгенерировал TAP файл;
- Домашний оператор получил TAP файл, произвел оценку, оплатил услуги партнера, снял деньги с абонента и счастливо положил доход к себе на счет.
Ура, работает! Да, есть задержка, но что поделать, файловый интерфейс, куча проверок на каждой стороне, человеческий фактор, данные могут задерживаться. И тут начинается проблема, и называется она billshock.
Пользователь уезжает в роуминг, беззаботно пользуется услугами (или модный смартфон решает скачать обновление без ведома хозяина). Приезжает домой и получает счет для оплаты которого ему надо продать квартиру или машину. Печалька.
Денег у пользователя нет. Оператор конечно потрепет нервы, но раз денег нет, то откуда их взять то, и под натиском общественного мнения и ради спасения репутации долг спишет. Но договор меду операторами никто не отменял, абонент пользовался услугой, потому взаиморасчет должен быть, и домашний оператор теряет деньги, репутацию, не говоря уже о приключениях абонента.
Никого такая ситуация не устраивает. Какие могут быть решения?
Внедрение полностью предоплатного способа расчетов кажется наиболее логичным, но не тут то было.
Огромную часть прибыли из роуминга дают корпоративные клиенты. Их сажать не prepaid нельзя. Почему? Да по ряду причин, некоторых конечно можно, но большинство — нельзя.
Операторы-партнеры во всяких экзотических для нас стран, мягко говоря, могут быть не сильно компетентны, у них может и не быть нужных технологий для организации препейда «по рекомендациям»… А абонент хочет говорить, а оператор снизить свои риски.
И начинается самое интересное, внедрение технологий, которые не дадут абоненту проговорить все свое имущество:
NRTRDE (Near Realtime Roaming Data Exchange)
Технология предназначена для смягчения возможного billshock. В чем суть, TAP файл штука медленная, и может прийти и в следующем месяце, на его основании абоненту выставляют счета. NR файл должен приходить минимум каждые 4 часа (вообще чаще, и у нормальных операторов мониторинг поднимает панику, если такие файлы перестали приходить), а специальная система анализирует стоимость услуг, счет абонента, кредитный лимит и не дает уйти в пике.
Да, за 4 часа можно скачать серию Интернов, но не все сезоны. Это в какой то мере защищает и абонента, и оператора от злых партнеров, которые выставляют цены на роуминг данных с потолка (да, я считаю что цены на передачу данных берут с потолка, внятного обоснования таим ценам на интерконнект я не вижу, соответственно достается и абоненту).
Плюсы: просто, GSMA сделало процедуру обмена NR файлами обязательной, работает для всех видов услуг и принимающая абонента сторона простимулирована отправлять NR файлы, т.к. если файла не было, а огромный счет есть, то никто такому оператору платить не будет, clearing-house организует доставку файлов между операторами, не надо плодить сущности.
Минусы: файловый интерфейс и все присущие ему проблемы.
Технология описана в рекомендации GSMA TD.35, к сожалению не могу ее выложить, но в сети можно поискать.
CAMEL в роуминге
- CAP1 — самая первая реализация. Сейчас отдельно не используется
- CAP2 — Позволяет проводить оценку голоса.
- CAP3 — К голосу добавляются исходящие SMS (только исходящие), и услуги передачи данных
- CAP4 — Полный контроль SMS и еще много всего, но рассматривать здесь не буду
- Завернуть весь SMS трафик на Prepaidплатформу и пусть работает как прокси. Решение работоспособное, достаточно простое, но и минусы всем понятны: еще одна точка отказа, лишняя нагрузка;
- Реализовать нестандартный протокол между SMSC и Prepaid, их много, особенно это популярное явление в моновендорной сети, очень любят производители подсаживать на свои протоколы, притом все подряд. Видимо осталось в виде атавизма, т.к. DIAMETER стабилизировался несколько лет назад.
- Прикрутить к SMSC DIAMETER. Всем решение хорошо, только вот апгрейд старых SMSC очень часто обходится в астрономическую сумму. Вендоры то не дураки, знают что оператор рано или поздно купит.
Оценка данных в CAP3/4 — в зачаточном состоянии, не поддерживается оценка контента, для роуминга подходит хорошо, но если есть DIAMETER, то зачем плодить сущности.
Call-Back.
Diameter и OCS.
Протокол DIAMETER является логичным развитием RADIUS, если интересно могу потом рассказать про них отдельно. Изначально он описывался RFC 3588 Diameter Base Protocol, потом получил развитие в рамках RFC 4006 Diameter Credit Control Application, и комитет 3GPP развил и описал его использование в нескольких рекомендациях, например 3gpp 32.299.
Отличный протокол, логично выстроен, просто расширяем, лишен детских болезней RADIUS. Но есть одно но, с учетом того что рекомендаций DIAMETER много, 3gpp выпустил много версий спецификаций, и каждый производитель оборудования волен добавлять в него свои структуры. В итоге у при использовании оборудования разных вендоров есть шанс получить железки с DIAMETER, но они будут несовместимы. Сейчас ситуация выправляется, но даже пару лет назад интеграция могла преподнести неприятные сюрпризы. Особенно это заметно на больших сетях. В полной мере это оказывает влияние и на оценку SMS.
Итого
- Технически есть все средства для корректной оценки в роуминге;
- Операторы не меньше абонентов должны быть заинтересованы в нормальной оценке;
- Корректной оценке услуг адекватных операторов мешают операторы-партнеры, которые не реализовали по той или иной причине функционал для онлайн оценки.
В следующей статье (если не разленюсь) попробую рассказать про применение DIAMETER и RADIUS.
Читайте также: