SMPP - Peer-to-Peer Short Message Protocol

Hallo! Selv om instant messengers og sosiale nettverk erstatter tradisjonelle kommunikasjonsmetoder hver dag, forringer ikke dette populariteten til SMS. Bekreftelse på et populært nettsted, eller en transaksjonsvarsling gjentar de lever og vil leve. Har du tenkt på hvordan det hele fungerer? Svært ofte brukes SMPP-protokollen til å sende bulkmeldinger, som vil bli diskutert under kuttet.

Habré hadde allerede artikler om smpp, 1,2, men deres formål var ikke å beskrive selve protokollen. Selvfølgelig kan du umiddelbart starte fra kilden - spesifikasjoner, men jeg tror det ville vært fint om det var en oppsummering av innholdet. Jeg vil forklare å bruke v3.4 som et eksempel.Jeg er glad for din objektive kritikk.

SMPP-protokollen er en peer-to-peer meldingsprotokoll. Dette betyr at hver peer/hub-server er like. I det enkleste tilfellet ser SMS-meldingsskjemaet slik ut:

SMPP - Peer-to-Peer Short Message Protocol

Men hvis den nasjonale operatøren ikke har en rute, ber han en mellommann om dette til en avsidesliggende region - en SMS-hub. Noen ganger, for å sende én SMS, må du bygge en kjede mellom flere land, eller til og med kontinenter.

Om protokoll

SMPP er en applikasjonslagsprotokoll som er basert på utveksling av PDUer og overføres over TCP/IP, eller X25-sesjoner for sending av sms- og ussd-meldinger. Vanligvis brukes SMPP i vedvarende tilkoblingsmodus, noe som sparer tid. SMPP bruker en klient-server kommunikasjonsmodell.

Kommunikasjonsmodus

SMPP - Peer-to-Peer Short Message Protocol

Utveksling av meldinger mellom avsender og SMS-senter via SMPP kan utføres i følgende moduser:

Sender (sender) - overføring av en melding i én retning, etter tur
Mottaker (mottaker) - mottar kun melding fra SMS-senteret.
Transceiver (transceiver) - Meldingsutveksling mellom SMS-sentralen og brukeren

Struktur

SMPP - Peer-to-Peer Short Message Protocol

Meldingslengde

Én SMS-melding kan inneholde 70 tegn når du skriver på kyrillisk og ikke mer enn 157 latinske tegn + 3 UDH Sender du en SMS med et stort antall tegn, vil den deles inn i flere segmenter og kombineres i mottakerenheten. Ved segmentering reduseres antall tegn med meldingshodene, som indikerer delen av meldingen. Derfor, når du sender en stor SMS-melding, inneholder den maksimalt 153 latinske tegn eller 67 ikke-typiske tegn.

Datakodeskjema

Imidlertid må tegn kodes for å formidle en melding. I SMPP-protokollen er et spesialfelt ansvarlig for koding - Data Coding Scheme, eller DCS. Dette er et felt som spesifiserer hvordan meldinger skal gjenkjennes. I tillegg inkluderer DCS-feltet:

  • tegnsettet som definerer kodingen;
  • meldingsklasse;
  • forespørsel om automatisk sletting etter lesing;
  • en indikasjon på meldingskomprimering;
  • språk for kringkasting av meldinger;

Standard 7-biters alfabet (GSM 03.38). Den ble utviklet for meldingssystemet i GSM. Denne kodingen passer for engelsk og en rekke latinske språk. Hvert tegn består av 7 biter og er kodet til en oktett.

UTF-16 (i GSM UCS2) For å inkludere manglende tegn i 7-biters alfabetet, ble UTF-16-kodingen utviklet, som legger til flere tegn (inkludert kyrilliske) ved å redusere meldingsstørrelsen fra 160 til 70, denne typen koding nesten fullstendig gjentar Unicode.

8-biters brukerdefinerte data. Disse inkluderer KOI8-R og Windows-1251. Selv om denne løsningen ser ut til å være mer økonomisk sammenlignet med samme UTF-16. Det er et rimelig spørsmål om kompatibilitet på forskjellige enheter. Siden i dette tilfellet må begge enhetene konfigureres på forhånd.

Meldingsklasse

  • Class0, eller flash, en melding lagret i telefonens minne på forespørsel fra brukeren;
  • Klasse1, eller de som er lagret i telefonens minne;
  • Klasse1, eller de som er lagret i telefonens minne;
  • Klasse2, må sørge for at meldingen er lagret i minnet til mobilterminalen, ellers må gi melding til SMS-senteret om manglende evne til å lagre;
  • Klasse3 - i dette tilfellet skal telefonen sende et varsel om at meldingen kan lagres, uavhengig av mengden minne i enheten. Denne typen melding innebærer at meldingen har nådd målet;

Meldingstype

Stille melding (SMS0) SMS-meldingstype uten innhold. Slik SMS kommer uten varsel og vises ikke på enhetens skjerm.

PDUer

Hver pdu-operasjon er sammenkoblet og består av en forespørsel og et svar. For eksempel: en kommando som sier at en tilkobling er opprettet (bind_transmitter / bind_transmitter_resp), eller at en melding er sendt (deliver_sm / delivery_sm_resp)

SMPP - Peer-to-Peer Short Message Protocol

Hver pdu-pakke består av to deler - en header (header) og en body (body). Overskriftsstrukturen er den samme for enhver pdu-pakke: kommandolengde er lengden på pakken, id er navnet på pakken, og statuskommandoen indikerer om meldingen ble sendt vellykket eller mislyktes.

Ytterligere TLV-parametere

TLV (Tag Length Value), eller tilleggsfelt. Slike parametere brukes til å utvide funksjonaliteten til protokollen og er valgfrie. Dette feltet er spesifisert på slutten av pdu-feltet. Som et eksempel, ved å bruke dest_addr_np_information TLV, kan du organisere overføringen av informasjon om portering av nummeret.

Ton og Npi

TON (Type of Number)-parameter informerer SMSC om adresseringsformatet og nettverkstypen.
NPI (Numbering Plan Identification) parameter som indikerer nummereringsplanen.

SMPP - Peer-to-Peer Short Message Protocol

Meldingskildeadresse, eller alfanavn

Meldinger som sendes til telefonen kommer i to varianter: numerisk og alfabetisk. Tall kan være lange (ligner på et telefonnummer) eller korte. Noen ganger har operatører begrensninger på å sende fra nøytrale navn, som Infosms, Alert etc. Noen ganger tillater ikke operatører trafikk hvis navnet ikke er registrert i nettverket deres. Dette er imidlertid mer en funksjon for operatøren.

Innleveringsstadier

SMPP - Peer-to-Peer Short Message Protocol

SMS-SEND inn sender MO FSM-melding (kortmelding fra mobilterminal)
SMS-SEND RAPPORT — bekreftelse på at meldingen ble sendt av SMSC
SRI SM (SendRoutingInfo) - SMSC mottar informasjon fra HLR angående MSC/VLR-posisjonen til abonnenten
SRI SM RESP — svar fra HLR angående abonnentposisjonskjøtt
MT-FSM - etter mottak av posisjonen, sendes en melding ved hjelp av "Videresend kort melding"-operasjonen
MT-FSM-ACK — svar fra SMSC om at meldingen er sendt
SMS STATUS RAPPORT — SMSC sender meldingsleveringsstatus.

Status for meldingslevering

SMS STATUS RAPPORT kan ha flere verdier:
DELIVRD meldingen ble levert
AVVISET — melding avvist av SMS-senteret
UTLØPT - meldingen fjernes fra sendekøen etter slutten av TTL (meldingslevetid)
UDELEV - andre tilfeller av manglende levering
UKJENT- Ingen svar mottatt.

Overføringsfeil

Noen ganger er årsakene til at SMS-meldinger ikke blir levert til abonnenten. Konsekvensen av disse årsakene er forekomsten av feil. Feil returneres i PDUs_sms_resp. Alle feil kan deles inn i midlertidig (midlertidig) og permanent (permanent).

Som et eksempel er absent_subscriber midlertidig, abonnenten er ikke tilgjengelig eller ikke online, og permanent - abonnenten eksisterer ikke. Avhengig av feilene som oppstår, dannes en policy for å sende disse meldingene på nytt.

For eksempel, hvis abonnenten var opptatt med å snakke og mottok en MT-håndsett er opptatt-feil, kan meldingen sendes på nytt etter noen minutter, men hvis abonnenten har blokkert tjenesten for meldingsmottak, vil det ikke gi mening å sende på nytt. Du kan finne en liste over feil på SMSC-sidene, for eksempel som dette.

Kilde: www.habr.com

Legg til en kommentar