Diameter Credit-Control Application
Diameter Credit-Control Application je síťový protokol pro aplikaci DIAMETER používanou pro implementaci účtování v reálném čase pro různé služby pro koncové uživatele.
Jde o IETF standard poprvé definovaný v RFC 4006 a aktualizovaný v RFC 8506.
Účel
[editovat | editovat zdroj]Účelem aplikace Diameter Credit-Control Application pro kontrolu kreditu je poskytovat rámec pro účtování v reálném čase, který je primárně určen pro komunikaci mezi branami/kontrolními body a koncovými body, které provádění správu účtů/zůstatků (typicky systém online účtování).
Aplikace specifikuje metody pro:
- Správu kvót (Reserve, Reauthorize, Abandon)
- Jednoduchý Debit/Credit
- Kontroly zůstatku
- Dotazy na cenu
Diameter Credit-Control applikace neudávají, jaký typ jednotek je používán nebo nakoupen a jaké položky jsou účtovány. To je ponecháno na kontextu služby, který musí být specifikován samostatně, stejně jako některé sémantické prvky.
Příklady použitých/nakoupených jednotek:
- Čas
- Byty uploadu/downloadu
- SMS (textové zprávy)
Příklady účtovaných položek:
- Peníze
- Body
- Jednotky (pokud je například zůstatek veden ve stejných jednotkách, jaké se používají)
Diameter Credit-Control Application také určuje, jak zpracovávat poměrně složitou problematiku více typů jednotek použitých nebo naúčtovaných k zůstatku jednoho uživatele. Uživatel může například platit jak za online čas tak za stažené byty ale má pouze jeden zůstatek účtu.
Účtování podle relací
[editovat | editovat zdroj]Účtování podle relací používá několik dotazů který může zahrnuje první, střední a poslední dotaz. Při dotazu jsou rezervovány peníze (prostředky) na účtu uživatele. Účtování podle relací se typicky používá pro scénáře kdy se účtované jednotky spotřebovávají spojitě, například účtování za přenesené byty.
Účtování podle událostí
[editovat | editovat zdroj]Účtování podle událostí používá události jako mechanismus účtování. Účtování podle událostí se typicky používá pro jednotky, které nejsou spojitě spotřebovávány, například při posílání MMS zpráv.
Kódy příkazů
[editovat | editovat zdroj]Pro Diameter Credit Control slouží dvě diametrové zprávy, CCR (Credit Control Request) a CCA (Credit Control Answer). Obě mají v RFC 4006 definovaný kód příkazu 272.
Pro správu kvót klient pošle na server zprávu CCR požadující jednotky a oznamující spotřebu. Server přidělí jednotky a zinkasuje uživatele. Pro jednoduché účtování debit/credit klient posílá CCR požadující odečtení jednotek z uživatelova účtu nebo přičtení jednotek k uživatelově účtu. Při dotazech na cenu pošle klient dotaz na server, jaká je cena za jednotku, a server vrátí cenu.
Toky zpráv
[editovat | editovat zdroj]Toky zpráv jsou obecně řízeny kontrolním bodem, který žádá o jednotky a serverem, který je poskytuje. Zprávu může také generovat jiná aplikace Diametru, např. NASREQ (RFC4005) pro relace, které jsou omezeny časově nebo objemem použití.
Následující schéma ukazuje zjednodušený tok zpráv pro relaci využívající přidělování kvót.
Klient začíná tím, že si ze serveru vyžádá 10 jednotek. Server ověří, že uživatel má pro operaci dostatečný zůstatek. V tomto příkladě server přidělí uživateli všechny požadované jednotky. Pokud by uživatel neměl nedostatečný zůstatek, mohlo by mu být přiděleno méně jednotek nebo by mohl být požadavek úplně zamítnut.
Když účastník relace spotřebuje přidělené jednotky, klient pošle na server aktualizaci oznamující kolik jednotek bylo použito a kolik jich chce nově přidělit. Klient také může požádat o jednotky před úplným vyčerpáním přidělených jednotek, aby se zabránilo pozastavení relace účastníka při komunikaci se serverem. V tomto příkladě klient pošle požadavek, když bylo spotřebováno 7 jednotek z 10; a požádá o dalších 10 jednotek, které server přidělí. Server může použít počet spotřebovaných jednotek pro odepsání ze zůstatku účastníka (přidělení jednotek neznamená, že budou použity; skutečné použití indikuje Used-Units AVP). Server také může sdělit klientovi, jak dlouho je přidělení platné; v takovém případě se očekává, že klient pošle aktualizaci, když časovač přidělení vyprší.
V rámci jedné relace může být mnoho aktualizačních zpráv.
Nakonec účastník ukončí relaci, a klient odešle na server zprávu o ukončení obsahující poslední použité jednotky v Used-Units. Server může zprávu o ukončení použít k vymazání všech rezervací provedených v back-end systému správy zůstatku. Pokud by účastník neukončil relaci sám, ale místo toho by vyčerpal svůj zůstatek, pak by server odpověděl dříve odmítnutím aktualizační zprávy, případně by klientovi/kontrolnímu bodu sdělil, že má přesměrovat provoz (to má obvykle smysl pouze pro provoz Hypertext Transfer Protocol/WAP).
AVP matice
[editovat | editovat zdroj]AVP pro nové kódy příkazů
[editovat | editovat zdroj]Nové kódy příkazů CCA a CCR mohou vyžadovat některá AVP podle následující tabulky. AVP uvedené polotučně jsou nová AVP pro DCCA.
| Kód příkazu | ||
|---|---|---|
| Jméno atributu | CCR | CCA |
| Acct-Multi-Session-Id | 0–1 | 0–1 |
| Auth-Application-Id | 1 | 1 |
| CC-Correlation-Id | 0–1 | 0 |
| CC-Session-Failover | 0 | 0–1 |
| CC-Request-Number | 1 | 1 |
| CC-Request-Type | 1 | 1 |
| CC-Sub-Session-Id | 0–1 | 0–1 |
| Check-Balance-Result | 0 | 0–1 |
| Cost-Information | 0 | 0–1 |
| Credit-Control-Failure-Handling | 0 | 0–1 |
| Destination-Host | 0–1 | 0 |
| Destination-Realm | 1 | 0 |
| Direct-Debiting-Failure-Handling | 0 | 0–1 |
| Event-Timestamp | 0–1 | 0–1 |
| Failed-AVP | 0 | 0+ |
| Final-Unit-Indication | 0 | 0–1 |
| Granted-Service-Unit | 0 | 0–1 |
| Multiple-Services-Credit-Control | 0+ | 0+ |
| Multiple-Services-Indicator | 0–1 | 0 |
| Origin-Host | 1 | 1 |
| Origin-Realm | 1 | 1 |
| Origin-State-Id | 0–1 | 0–1 |
| Proxy-Info | 0+ | 0+ |
| Redirect-Host | 0 | 0+ |
| Redirect-Host-Usage | 0 | 0–1 |
| Redirect-Max-Cache-Time | 0 | 0–1 |
| Requested-Action | 0–1 | 0 |
| Requested-Service-Unit | 0–1 | 0 |
| Route-Record | 0+ | 0+ |
| Result-Code | 0 | 1 |
| Service-Context-Id | 1 | 0 |
| Service-Identifier | 0–1 | 0 |
| Service-Parameter-Info | 0+ | 0 |
| Session-Id | 1 | 1 |
| Subscription-Id | 0+ | 0 |
| Termination-Cause | 0–1 | 0 |
| User-Equipment-Info | 0–1 | 0 |
| Used-Service-Unit | 0+ | 0 |
| User-Name | 0–1 | 0–1 |
| Validity-Time | 0 | 0–1 |
Nová AVP pro kódy příkazů základního protokolu
[editovat | editovat zdroj]| Kód příkazu | ||
|---|---|---|
| Jméno atributu | RAR | RAA |
| CC-Sub-Session-Id | 0–1 | 0–1 |
| G-S-U-Pool-Identifier | 0–1 | 0–1 |
| Service-Identifier | 0–1 | 0–1 |
| Rating-Group | 0–1 | 0–1 |
V tabulce jsou použity následující symboly:
- 0 AVP NESMÍ být přítomno ve zprávě
- 0+ Nula nebo více instancí AVP MŮŽE být přítomna ve zprávě
- 0–1 Žádná nebo jedna instance AVP MŮŽE být přítomna ve zprávě; je považováno za chybu, pokud je ve zprávě více než jedna instance AVP
- 1 Jedna instance AVP MUSÍ být přítomna ve zprávě
- 1+ Alespoň jedna instance AVP MUSÍ být přítomna ve zprávě
Standardy
[editovat | editovat zdroj]- IETF RFC 4005 – Diameter Network Access Server Application
- IETF RFC 4006 – Diameter Credit-Control Application (zastaralý)
- IETF RFC 8506 – Diameter Credit-Control Application
- 3GPP 32.299 - 3GPP Telecommunication management - Charging management - Diameter charging applications.
Odkazy
[editovat | editovat zdroj]Reference
[editovat | editovat zdroj]V tomto článku byl použit překlad textu z článku Diameter Credit-Control Application na anglické Wikipedii.