Short Message Peer to Peer

Short Message Peer to Peer (SMPP) protokol je otevřený telekomunikační protokol, který slouží k posílání SMS zpráv mezi SMS Centry (SMSC) a externími aplikacemi (ESME) jako WAP Proxy server, Emailové brány nebo Voice Mail systémy, které nejsou připojeny přímo do mobilní sítě.

Historie

SMPP bylo navrženo malou irskou firmou Aldiscon. V roce 1997 se firma Aldiscon stala telekomunikační divizí firmy Logica, v roce 2007 byla odprodána soukromým investorům jako firma Acision, po spojení s firmou Comverse v roce 2015 pak vystupuje pod jménem Xura. +more Protokol SMPP vytvořil vývojář Ian Chambers, původně pro testování funkčnosti SMS Center bez připojení do SS7 sítě. V roce 1999 byl protokol otevřen a Logica oficiálně předala správu nad SMPP protokolem sdružení firem a developerů s názvem SMPP Developer Forum, později The SMS Forum. K poslednímu červenci 2007 se Forum rozpustilo s tím, že splnilo svůj účel a další změny v protokolu nejsou nutné, a správa SMPP protokolu se vrátila pokračovateli firmy Aldiscon - firmě Mavenir.

Nejrozšířenější verzí protokolu je SMPP 3.4, poslední verzí je pak SMPP 5.0.

Přehled

SMPP protokol definuje * sadu operací (a jejich PDU) sloužících k posílání zpráv mezi ESME a SMSC * data, která si ESME aplikace/SMSC musí vyměnit během SMPP operací

Rozlišujeme 3 typy spojení mezi ESME a SMSC podle kterých se dále určují PDU (packet data unit, - pakety), která se smí s daným typem použít: * Transmitter (TX | bind_transmitter) - přes takové spojení je klient (ESME) schopen odesílat zprávy k serveru (SMSC) - submit_sm * Receiver (RX | bind_receiver) - přes takové spojení je klient (ESME) schopen přijímat zprávy od serveru (SMSC) - deliver_sm * Transceiver (TRX | bind_transceiver) - přes takové spojení je klient (ESME) schopen odesílat i přijímat zprávy k/od serveru (SMSC) - submit_sm i deliver_sm - zavedený od SMPP verze 3.4

Protokol funguje způsobem požadavku a odpovědi na 4. vrstvě ISO/OSI protokolu (TCP nebo +more25'>X. 25 SVC3 spojení). Data jsou v binární formě kvůli efektivitě. Protokol funguje jak v synchronním (po každém požadavku se čeká na odpověď než se odešle požadavek další), tak asynchronním módu (pomocí Transaction Window Size se nastaví kolik daná entita může odeslat požadavků než obdrží odpověď na "první" z nich - počet on-the-fly požadavků).

Požadavkem se rozumí příkaz definovaný podle specifikace jako je odeslání zprávy (submit_sm (přes TX, TRX spojení), deliver_sm (RX, TRX), data_sm (TX, RX, TRX)), dotaz na stav již odeslané zprávy (query_sm), úprava zprávy (replace_sm), příp. zrušení (cancel_sm). +more Požadavky query_sm, replace_sm a cancel_sm předpokládají, že daná zpráva se stále nachází mezi nedoručenými zprávami na SMSC neboli SMSC ji stále má ve svém bufferu a může s ní pracovat.

Struktura

Hlavička (header) má pevnou velikost (16 oktetů). 4x 4 oktety pro * command_length - velikost PDU * command_id - typ PDU/požadavku * command_status - chybový kód, vztahuje se pouze k odpovědi - požadavek obsahuje nulovou hodnotu * sequence_number - id požadavku (identifikuje požadavek v případě asynchronního módu).

Tělo požadavku má 2 části. Povinnou část a Volitelnou část. +more Každý typ požadavku má definovány atributy pro své povinné parametry (velikost a typ) a i jejich pořadí je definováno specifikací. Volitelná část zprávy se přidává na konec PDU a jejich uspořádání není nijak předepsáno, jelikož se udávají ve formě TLV (tag, length, value). Uvnitř daného PDU mohou být zahrnuty jen některé, všechny nebo žádné z volitelných parametrů.

Externí odkazy

[url=http://docs. nimta. +morecom/SMPP_v3_4_Issue1_2. pdf]Short Message Peer to Peer Protocol Specification v3. 4[/url] * [url=http://docs. nimta. com/smppv50. pdf]Short Message Peer to Peer Protocol Specification v5. 0[/url].

Kategorie:Telekomunikace