Signalling Connection Control Part
Signalling Connection Control Part (SCCP) je protokol síťové vrstvy v signalizačním systému č. 7 používaném v telefonních sítích. Umožňuje směrování signalizačních zpráv (a SMS) podle telefonních čísel nebo čísel IMSI – v SCCP jsou tyto adresy součástí struktury nazývané Global Title. SCCP může také poskytovat řízení toku dat, segmentaci, spojované služby a opravu chyb. Klasické SCCP využívá při přenosu v SS7 sítích pro základní směrování a detekci chyb služeb síťového protokolu Message Transfer Part (MTP). V SIGTRAN se pro přenos SCCP v TCP/IP sítích využívá transportní protokol SCTP. Vrstvu SCCP je možné rozdělit na 4 části:
- směrování (routing)
- nespojované řízení (connectionless control)
- spojované řízení (connection-oriented control)
- správa (management)
| OSI vrstva | SS7 protokoly |
|---|---|
| Aplikační | TCAP, MAP, IS-41, INAP, CAP |
| Síťová | SCCP, SIGTRAN (IP7) |
| Linková | MTP Level 2 |
| Fyzická | MTP Level 1 |
SCCP bylo definováno v roce 1988 v Blue Book jako ITU Q.713, později byly doplněny další vlastnosti.
SCCP Třídy
SCCP poskytuje jak spojované (anglicky connection-oriented) tak nespojované (anglicky connectionless) síťové služby. SCCP rozlišuje 4 třídy služeb:
- Class 0 SCCP Základní nespojované (Basic Connectionless)
- Class 1 SCCP Nespojované zachovávající pořadí paketů (Sequenced Connectionless)
- Class 2 SCCP Základní spojované (Basic Connection Oriented)
- Class 3 SCCP Spojované s řízením toku dat (Flow Control Connection Oriented)
Pro třídy 0 a 1 se nevytváří logické spojení, proto každá zpráva musí nést adresu příjemce. Pro třídy 2 a 3 se vytváří spojení a pro odkaz na spojení se používá Source Local Reference (SLR) a Destination Local Reference (DLR). Třídy 2 a 3 umožňují vytvořit více logických spojení mezi dvěma signalizačními body (Signalling Point – SP). Toho se využívá na rozhraní mezi MSC a BSC (A-interface), kde je potřeba mít samostatné spojení pro každou mobilní stanici.
Zatímco v třídě 0 může každá zpráva jít po jiných linkách a na zachování pořadí zpráv se nijak nedbá, při použití třídy 1 budou zprávy díky nastavení SLS v MTP posílány týmiž linkami (pokud to jde) a díky tomu, že MTP zachovává pořadí zpráv, by měly témuž příjemci docházet v tom pořadí, v jakém byly odeslány.
Pro komunikaci mezi MSC, HLR, VLR, EIR pomocí protokolu MAP (přenášeném v TCAP) se používají connectionless služby (SCCP zprávy UDT), pro komunikaci mezi MSC a BSC se používají connectionless i connection-oriented služby.
Druhy SCCP zpráv
Každá SCCP zpráva začíná oktetem Message Type (MT) určujícím druh zprávy:
| MT | 0 | 1 | 2 | 3 | zkratka | zpráva |
|---|---|---|---|---|---|---|
| 1 | – | – | + | + | CR | Connection request |
| 2 | – | – | + | + | CC | Connection confirm |
| 3 | – | – | + | + | CREF | Connection refused |
| 4 | – | – | + | + | RLSD | Released |
| 5 | – | – | + | + | RLC | Release complete |
| 6 | – | – | + | – | DT1 | Data form 1 |
| 7 | – | – | – | + | DT2 | Data form 2 |
| 8 | – | – | – | + | AK | Data acknowledgement |
| 9 | + | + | – | – | UDT | Unitdata |
| 10 | + | + | – | – | UDTS | Unitdata service |
| 11 | – | – | – | + | ED | Expedited data |
| 12 | – | – | – | + | EA | Expedited data acknowledgement |
| 13 | – | – | – | + | RSR | Reset request |
| 14 | – | – | – | + | RSC | Reset confirm |
| 15 | – | – | + | + | ERR | Protocol data unit error |
| 16 | – | – | + | + | IT | Inactivity test |
| 17 | + | + | – | – | XUDT | Extended unitdata |
| 18 | + | + | – | – | XUDTS | Extended unitdata service |
| 19 | + | + | – | – | LUDT | Long unitdata |
| 20 | + | + | – | – | LUDTS | Long unitdata service |
Zprávy UDT mohou nést maximálně 252 oktetů. Delší zprávy je možné segmentovat a přenášet pomocí XUDT (až 251 oktetů na segment), nebo přenášet pomocí LUDT (až 3904 oktetů). LUDT zprávy mohou být používány pouze na vysokorychlostních linkách (linka T1 nebo E1).
Zprávy typu UDTS (Unitdata service), XUDTS a LUDTS se používají pro indikaci, že odeslaná zpráva UDT, XUDT příp. LUDT (která měla nastavený parametr Return Message on Error) nelze doručit požadovanému příjemci. U zpráv UDTS, XUDTS a LUDTS nelze stanovit třídu, protože neobsahují parametr protocol class. Výjimečně se zprávu UDTS mohou používat i pro odezvy na XUDT a LUDT.
Spojované (anglicky Connection-oriented) SCCP zprávy mezi MSC a BSC:
- CR Connection Request – zpráva pro navázání spojení
- CC Connection Confirmed – odpověď na CR
- DT1 Dataform 1 – pro přenos dat při použití Class 2
- RLSD Released – ukončuje spojení
- RLC Release Completed – potvrzení RLSD
Nespojované (anglicky Connectionless) SCCP zprávy mezi MSC a BSC:
- UDT Unit Data (Message Type=9)
- UDTS Unitdata service
Při použití Class 3 se pro přenos dat používá DT2 (Dataform 2) a pro jejich potvrzování AK.
Formát SCCP zpráv
SCCP rozeznává tři typy parametrů:
- F = povinné parametry s pevnou délkou
- V = povinné parametry s proměnnou délkou
- O = nepovinné parametry s pevnou nebo proměnnou délkou
Různé SCCP zprávy mají různý počet parametrů.
Formát zprávy UDT
Zprávy typu UDT (Unitdata) mají následující strukturu:
| oktetů | typ | parametr |
|---|---|---|
| 1 | – | Message Type (MT) |
| 1 | F | Protocol Class and Return Message on Error |
| min. 3 | V | Adresa volaného (Called Party Address – CdPA) |
| min. 3 | V | Adresa volajícího (Calling Party Address – CgPA) |
| min. 2 | V | Data |
Na začátku zprávy je vždy jeden oktet obsahující Message Type, následují parametry typu F, pak ukazatele na parametry typu V a případný ukazatel na začátek části s parametry typu O. Ukazatel je jednobytová (u zpráv LUDT a LUDTS dvoubytová – little endian) hodnota udávající, kolik bytů za začátkem ukazatele začíná vlastní parametr. Parametry typu V začínají oktetem s délkou (Length Indicator – LI). Parametry typu O začínají jedním oktetem identifikujícím parametr (Parameter Name) a jedním oktetem s délkou; pak následuje hodnota parametru. Za posledním parametrem typu O je oktet s hodnotou 0, který signalizuje konec parametrů typu O.
Proto zpráva UDT vypadá detailněji takto:
- 1 oktet Message Type (MT); 9 = UDT (Unitdata)
- 1 oktet Protocol Class; nejvyšší bit 1 Return message on error, 0 No Return Message on Error nejnižší 2 bity SCCP Class 0x80 = Class 0, 8 = Message handling = Return message on error
- 1 oktet ukazatel na první parametr typu V – u UDT to je Called Party Address
- 1 oktet ukazatel na druhý parametr typu V – u UDT Calling Party Address
- 1 oktet ukazatel na třetí parametr typu V – u UDT Data
- 1 oktet LI (délka) Called Party Address parameter
- n oktetů Called Party Address parameter
- 1 oktet LI (délka) Calling Party Address parameter
- n oktetů Calling Party Address parameter
- 1 oktet LI (délka) Data parameter
Formát zprávy UDTS
Zprávy typu UDTS (Unitdata service) mají následující strukturu:
| oktetů | typ | parametr |
|---|---|---|
| 1 | – | Message Type (MT) |
| 1 | F | Return Cause |
| min. 3 | V | Adresa volaného (Called Party Address – CdPA) |
| min. 3 | V | Adresa volajícího (Calling Party Address – CgPA) |
| min. 2 | V | Data |
Kde pole Return Cause může nabývat následujících hodnot:
| Hodnota | Význam |
|---|---|
| 0 | převod adres tohoto typu není definován (no translation for an address of such nature) |
| 1 | převod adresy není definován (no translation for this specific address) |
| 2 | zahlcení subsystému (subsystem congestion) |
| 3 | selhání subsystému (subsystem failure) |
| 4 | nevybavený uživatel (unequipped user) |
| 5 | selhání MTP (MTP failure) |
| 6 | zahlcení sítě (network congestion) |
| 7 | blíže neurčená chyba (unqualified) |
| 16 | chyba při dopravě zprávy (error in message transport) – pouze pro XUDTS |
| 17 | chyba při místním zpracování (error in local processing) – pouze pro XUDTS |
| 18 | cílový uzel nemůže sestavit zprávu ze segmentů (destination cannot perform reassembly) – pouze pro XUDTS |
| 19 | selhání SCCP (SCCP failure) |
| 20 | překročen počet hopů (hop counter violation) |
| 21 | segmentace není podporována (segmentation not supported) |
| 22 | selhání segmentace (segmentation failure) |
| 23-228 | rezervováno pro mezinárodní použití |
| 229-254 | rezervováno pro národní sítě |
| 255 | rezervováno |
SCCP Adresy
Adresa odesilatele se v SCCP nazývá adresa volajícího (Calling Party Address – CgPA); adresa příjemce je adresa volaného (Called Party Address – CdPA). V SCCP zprávách třídy 0 a 1 jsou obě povinné (parametry typu V). SCCP adresy mohou obsahovat následující prvky:
| název | zkratka | délka | přítomen |
|---|---|---|---|
| Address Indicator | AI | 1 oktet | vždy |
| Signalling Point Code | SPC | ITU 2 oktety, ANSI 3 oktety | pokud SPC Indicator = 1 |
| Subsystem Number | SSN | 1 oktet | pokud SSN Indicator = 1 |
| Global Title | GT | proměnná délka | pokud GTI Indicator ≠ 0 |
Address Indicator (AI) udává, které součásti adresy jsou přítomné, a má následující strukturu:
| bit | pole | obsah |
|---|---|---|
| 8 | National/International | v ITU vždy 0 (nepoužito), v ANSI 1 = National |
| 7 | Routing Indicator (RI) | 0 = směrovat pomocí GT, 1 = směrovat pomocí SSN a SPC |
| 6-3 | Global Title Indicator (GTI) | viz níže |
| 2 | Subsystem Number Indicator | 1 = SSN je přítomen |
| 1 | Signalling Point Code Indicator | 1 = SPC je přítomen |
V ANSI sítích jsou bity 2 a 1 prohozeny. Kvůli tomu, kvůli rozdílné délce SPC a kvůli jinému významu jednotlivých hodnot GTI je nutné při práci s GT vždy vědět, jestli se jedná o ITU nebo ANSI síť. Při používání analyzátoru síťového provozu Wireshark je nutné správně nastavit Edit → Preferences → Protocols → MTP3 → MTP3 standard, jinak se budou špatně zobrazovat hodnoty Global Title nebo se nebude vůbec zobrazovat obsah SCCP paketů.
ITU Signalling Point Code (SPC) má 14 bitů. V SCCP je přenášen ve dvou po sobě jdoucích oktetech. V prvním oktetu je spodních 8 bitů SPC, v 6 spodních bitech druhého oktetu je zbývajících 6 bitů SPC. Horní dva bity druhého oktetu jsou nulové. V textovém tvaru se SPC zapisuje jako trojice desítkových čísel oddělených pomlčkou: síť-podsíť-uzel; síť je hodnota nejvyšších 3 bitů, podsíť dalších 8 bitů a uzel hodnota nejnižších 3 bitů.
ANSI Signalling Point Code má 24 bitů a je přenášen ve třech po sobě jdoucích oktetech. V prvním oktetu je číslo uzlu, ve druhém číslo podsítě, ve třetí číslo sítě. V textovém tvaru se SPC zapisuje jako tři desítková čísla oddělená pomlčkou: síť-podsíť-uzel.
Global Title
Global Title (GT) umožňuje směrování signalizačních zpráv (a SMS) podle telefonních čísel nebo čísel IMSI nejen v síti jednoho operátora, ale po celém světě. Formát GT v SCCP adrese udává Global Title Indicator. Pokud je GTI=0, Global Title není přítomen.
Subsystem Number
Jednotlivé SCCP uživatele na stejném nodu lze rozlišit pomocí čísla subsystému (SSN – Subsystem number). Základní rozdělení SSN je následující:
| SSN | Význam |
|---|---|
| 0 | neznámé nebo nepoužité |
| 1-31 | pro mezinárodní použití |
| 32-254 | pro národní použití |
| 255 | rezervováno pro budoucí rozšíření |
Síťově specifické SSN se mají přidělovat sestupně od čísla 254.
Podle 3GPP TS 23.003[1] jsou následující SSN celosvětově přidělena pro GSM/UMTS sítě:
| SSN | Význam |
|---|---|
| 6 | domovský registr (Home Location Register – HLR) |
| 7 | návštěvnický registr (Visitor Location Register – VLR) |
| 8 | Mobile Switching Centre (MSC) |
| 9 | Equipment Identifier Centre (EIC) |
| 10 | rezervováno pro další vývoj (Authentication Centre – AuC) |
Následující národní SSN jsou přidělena pro použití uvnitř GSM/UMTS sítí a mezi GSM/UMTS sítěmi:
| SSN | Význam |
|---|---|
| 142 | RANAP |
| 143 | RNSAP |
| 145 | GMLC (MAP) |
| 146 | CAP |
| 147 | gsmSCF (MAP), IM-SSF (MAP) nebo síťový agent Presence |
| 148 | SIWF (MAP) |
| 149 | SGSN (MAP) |
| 150 | GGSN (MAP) |
Následující národní SSN jsou přidělena pro použití uvnitř GSM/UMTS sítí:
| SSN | Význam |
|---|---|
| 248 | CSS (MAP) |
| 249 | PCAP |
| 250 | BSC (BSSAP-LE) |
| 251 | MSC (BSSAP-LE) |
| 252 | SMLC (BSSAP-LE) |
| 253 | BS O&M (rozhraní A) |
| 254 | Base Station System Application Part (BSSAP) na rozhraní A – spojově orientované služby mezi MSC a BSC |
Některé zdroje uvádějí následující přidělení čísel SSN:
| SSN | Význam |
|---|---|
| 0 | SSN not known/not used |
| 1 | SCCP Management |
| 2 | Reserved for CCITT allocation |
| 3 | ISDN User Part |
| 4 | Operation Maintenance & Administration Part (OMAP) |
| 5 | Mobile Application Part (MAP) |
| 6 | Home Location Register (HLR) |
| 7 | Visitor Location Register (VLR) |
| 8 | Mobile Switching Centre (MSC) |
| 9 | Equipment Identifier Centre (EIC) |
| 10 | Authentication Centre (AuC) |
| 11 | ISDN Supplementary Services; v ANSI SCCP SMS |
| 12 | Reserved for international use; v ANSI SCCP OTAF |
| 13 | Broadband ISDN edge-to-edge applications |
| 14 | TC Test responder |
| 15-31 | Reserved for international use |
| 32-254 | Reserved for national use |
| 254 | Base Station System Application Part (BSSAP) – connection oriented komunikace mezi MSC a BSC |
| 255 | Reserved for expansion of national and international SSN |
SSN obvykle pouze doplňují Point Code nebo Global Title. Ve specifických případech se ale používají i samostatně.
Při použití SSN, která identifikují protokoly MAP (včetně SSN 6 až 10) nebo CAP je v parametru Data TCAP zpráva. Vlastní MAP nebo CAP data jsou v komponentové části této TCAP zprávy, přičemž konkrétní aplikační protokol a jeho verze jsou určeny aplikačním kontextem, který byl dojednán v TCAP transakci; pokud žádný aplikační kontext nebyl dojednán, je použit protokol MAP verze 1.
Odkazy
Reference
Související články
Externí odkazy
- ITU-T doporučení Q.711 – Funkční popis SCCP
- ITU-T doporučení Q.712 – Definice a funkce SCCP zpráv
- ITU-T doporučení Q.713 – SCCP formáty a kódy
- ITU-T doporučení Q.714 – SCCP procedury
- ITU-T doporučení Q.1400 – Architektonický rámec pro vývoj protokolů pro signalizaci a správu s využitím OSI konceptů
- série Q ITU-T doporučení
- ANSI Signalling Connection Control Part (SCCP) SCCP document[nedostupný zdroj]