Diameter Credit-Control Application
Diameter Credit-Control Application to protokół sieciowy dla aplikacji Diameter , używany do implementacji kontroli kredytu w czasie rzeczywistym dla różnych usług dla użytkowników końcowych.
Jest to standard IETF zdefiniowany po raz pierwszy w RFC 4006 i zaktualizowany w RFC 8506.
Zamiar
Celem aplikacji do kontroli kredytowej Diament jest zapewnienie struktury do pobierania opłat w czasie rzeczywistym, przeznaczonej przede wszystkim do komunikacji między bramkami/punktami kontrolnymi a systemami konta/bilansu zaplecza (zwykle systemem opłat online ) .
Aplikacja określa metody dla:
- Zarządzanie limitami (rezerwacja, ponowna autoryzacja, rezygnacja)
- Proste obciążenie/kredyt
- Kontrola salda
- Zapytania o cenę
Aplikacja do kontroli kredytowej średnicy nie określa, jakie jednostki typu są kupowane/używane i które pozycje są naliczane. Pozostawia się to kontekstowi usługi, który należy określić osobno, podobnie jak niektóre semantyki.
Przykłady używanych/kupionych jednostek:
- Czas
- Prześlij/pobierz bajty
- SMS (wiadomości tekstowe)
Przykłady naliczanych przedmiotów:
- Pieniądze
- Zwrotnica
- Jednostki (np. jeśli saldo jest utrzymywane w tych samych jednostkach, co używane)
Kontrola kredytowa Diameter określa również, jak radzić sobie z dość złożonym problemem wielu typów jednostek używanych/obciążanych w stosunku do salda jednego użytkownika. Na przykład użytkownik może płacić zarówno za czas online, jak i pobierane bajty, ale ma tylko jedno saldo konta.
Ładowanie na podstawie sesji
Proces kontroli kredytowej oparty na sesji wykorzystuje kilka zapytań, które mogą obejmować pierwsze, pośrednie i ostatnie zapytanie. Podczas przesłuchania pieniądze są rezerwowane z konta użytkownika. Opłaty oparte na sesjach są zwykle stosowane w scenariuszach, w których naładowane jednostki są zużywane w sposób ciągły, np. naliczanie opłat za wysyłanie/pobieranie bajtów.
Ładowanie oparte na zdarzeniach
Proces kontroli kredytowej oparty na zdarzeniach wykorzystuje zdarzenia jako mechanizm naliczania opłat. Opłaty oparte na zdarzeniach są zwykle stosowane, gdy jednostki nie są zużywane w sposób ciągły, np. użytkownik wysyła wiadomość MMS.
Kody poleceń
Aby wspierać kontrolę kredytową za pośrednictwem Diameter, istnieją dwa komunikaty Diameter, CCR (wniosek o kontrolę kredytową) i CCA (odpowiedź kontroli kredytowej). Kod polecenia dla CCR/CCA to 272, zgodnie z definicją w RFC 4006
W celu zarządzania przydziałami klient wysyła CCR do serwera, żądając jednostek i raportując zużycie. Serwer przyznaje jednostki i obciąża użytkownika. W przypadku prostego obciążenia/uznania klient wysyła CCR z prośbą do serwera o uznanie/obciążenie konta użytkownika. W przypadku zapytań o cenę klient pyta serwer, jaka jest cena za jednostkę, a serwer odpowiada ceną.
Przepływ wiadomości
Przepływy komunikatów są generalnie napędzane przez punkt kontrolny proszący o jednostki i serwer je przyznający. Wiadomość może być również generowana przez inne aplikacje o średnicy, takie jak NASREQ (RFC4005) dla sesji, które są ograniczone czasowo/użytkowaniem.
Na poniższym diagramie przedstawiono uproszczony przepływ komunikatów dla sesji przy użyciu przydziałów.
Klient zaczyna od zażądania od serwera 10 jednostek. Serwer sprawdza, czy użytkownik/abonent ma na to wystarczające saldo. W tym przykładzie serwer zapewnia klientowi wszystkie żądane przez niego jednostki. gdyby abonent miał niewystarczające saldo, mógł przyznać mniej jednostek lub całkowicie je odrzucić.
Kiedy lub zanim sesja abonencka wykorzysta przyznane jednostki, klient wysyła aktualizację do serwera, informując go, ile jednostek zostało wykorzystanych i ile chciałby przyznać tym razem. Klient może zażądać jednostek przed całkowitym wykorzystaniem poprzedniego przydziału, aby uniknąć zawieszenia sesji abonenckiej podczas rozmowy z serwerem. W tym przykładzie klient wysyła żądanie, gdy wykorzystano 7 jednostek z 10 przyznanych wcześniej jednostek; i poproś o 10 dodatkowych jednostek, które zapewnia serwer. Serwer może wykorzystać liczbę wykorzystanych jednostek do obciążenia konta abonenta (przyznanie jednostek nie oznacza, że zostaną one wykorzystane. AVP wykorzystanych jednostek zawiera faktyczne wykorzystanie). Możliwe jest również, aby serwer poinformował klienta, jak długo grant jest ważny, w którym to przypadku oczekuje się, że klient wyśle aktualizację po wygaśnięciu licznika czasu grantu.
Podczas sesji może pojawić się wiele komunikatów aktualizacyjnych.
Na koniec abonent zakończył sesję, a klient wysyła komunikat zakończenia do serwera zawierającego ostatnie używane jednostki. Serwer może użyć komunikatu o zakończeniu, aby usunąć wszelkie powiązane rezerwacje dokonane w systemie zarządzania saldem zaplecza. Jeśli subskrybent sam nie zakończył sesji, ale zamiast tego wyczerpał swoje saldo, serwer odpowiedziałby wcześniej odrzuceniem wiadomości aktualizacyjnej, prawdopodobnie nakazując klientowi/punktowi kontrolnemu przekierowanie ruchu (zwykle ma to sens tylko w przypadku ruchu HTTP / WAP ).
Macierz AVP
AVP dla nowych kodów poleceń
Nowe kody poleceń, CCA i CCR, mogą wymagać niektórych AVP, jak wskazano poniżej. Śmiałe AVP to nowość w DCCA.
| Kod polecenia | ||
|---|---|---|
| Nazwa atrybutu | CCR | CCA |
| Identyfikator-wielu sesji-konta | 0–1 | 0–1 |
| Identyfikator-aplikacji-uwierzytelniania | 1 | 1 |
| Identyfikator korelacji CC | 0–1 | 0 |
| Przełączanie awaryjne sesji CC | 0 | 0–1 |
| CC-Request-Numer | 1 | 1 |
| Typ żądania CC | 1 | 1 |
| CC-identyfikator-pod-sesji | 0–1 | 0–1 |
| Wynik sprawdzenia salda | 0 | 0–1 |
| Informacje o kosztach | 0 | 0–1 |
| Obsługa niepowodzeń w zakresie kontroli kredytowej | 0 | 0–1 |
| Host docelowy | 0–1 | 0 |
| Kraina Przeznaczenia | 1 | 0 |
| Obsługa awarii polecenia zapłaty | 0 | 0–1 |
| Sygnatura czasowa zdarzenia | 0–1 | 0–1 |
| Niepowodzenie-AVP | 0 | 0+ |
| Wskazanie jednostki końcowej | 0 | 0–1 |
| Jednostka przyznanej usługi | 0 | 0–1 |
| Kontrola wielu usług kredytowych | 0+ | 0+ |
| Wskaźnik wielu usług | 0–1 | 0 |
| Pochodzenie-Host | 1 | 1 |
| Kraina pochodzenia | 1 | 1 |
| Identyfikator stanu pochodzenia | 0–1 | 0–1 |
| Informacje o serwerze proxy | 0+ | 0+ |
| Host przekierowania | 0 | 0+ |
| Wykorzystanie hosta przekierowania | 0 | 0–1 |
| Redirect-Max-Cache-Time | 0 | 0–1 |
| Żądane działanie | 0–1 | 0 |
| Jednostka żądanej usługi | 0–1 | 0 |
| Zapis trasy | 0+ | 0+ |
| Kod wyniku | 0 | 1 |
| Identyfikator kontekstu usługi | 1 | 0 |
| Identyfikator usługi | 0–1 | 0 |
| Informacje o parametrach usługi | 0+ | 0 |
| Identyfikator sesji | 1 | 1 |
| Identyfikator subskrypcji | 0+ | 0 |
| Przyczyna zakończenia | 0–1 | 0 |
| Informacje o sprzęcie użytkownika | 0–1 | 0 |
| Używana jednostka serwisowa | 0+ | 0 |
| Nazwa użytkownika | 0–1 | 0–1 |
| Czas ważności | 0 | 0–1 |
Nowe AVP dla kodów poleceń protokołu podstawowego
| Kod polecenia | ||
|---|---|---|
| Nazwa atrybutu | RAR | RAA |
| CC-identyfikator-pod-sesji | 0–1 | 0–1 |
| Identyfikator puli GSU | 0–1 | 0–1 |
| Identyfikator usługi | 0–1 | 0–1 |
| Grupa ratingowa | 0–1 | 0–1 |
W tabeli zastosowano następujące symbole:
- 0 The AVP MUST NOT be present in the message
- 0+ W wiadomości MOŻE być obecnych zero lub więcej wystąpień AVP
- 0–1 Zero lub jedna instancja AVP MOŻE być obecna w wiadomości. Uznaje się za błąd, jeśli istnieje więcej niż jedna instancja AVP
- 1 Jedna instancja AVP MUSI być obecna w wiadomości
- 1+ Co najmniej jedna instancja AVP MUSI być obecna w wiadomości
Powiązane normy
- RFC 4005 — aplikacja serwera dostępu do sieci Diameter.
- RFC 4006 — Aplikacja kontroli kredytu Diameter (przestarzała)
- RFC 8506 — Aplikacja kontroli kredytu Diameter.
- 3GPP 32.299 - 3GPP Zarządzanie telekomunikacją - Zarządzanie ładowaniem - Aplikacje do ładowania według średnicy.