Диаметрлік несие басқару протоколы және оның қолданылуы
Diameter Credit-Control Application
Диаметр несие бақылау қосымшасы – нақты уақыт несие бақылауы үшін желілік хаттама. Сессиялық есептеу, ақша резерві, деректерді жүктеу/қою үшін қолданылады.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Diameter Credit Control Application – диаметрлік қосымшаны қолданатын желілік протокол, ол әртүрлі соңғы пайдаланушылар қызметтері үшін нақты уақыт режимінде несиелік бақылауды жүзеге асыруға арналған. Бұл IETF стандарты, алғаш рет RFC 4006 құжатында сипатталған және RFC 8506 құжатында жаңартылған.
Diameter Credit Control Application is a networking protocol for Diameter application used to
implement real time credit control for a variety of end user services. It is an IETF standard first defined in RFC 4006, and updated in RFC 8506.
Сессияға негізделген ақы төлеу
Сессиялық негіздегі кредиттік бақылау процесі бірнеше тексерулерді пайдаланады, олар бастапқы, аралық және соңғы тексерулерді қамтуы мүмкін. Тексеру кезінде пайдаланушы шотынан қаражат резервтеледі. Сессиялық төлемақы көбінесе зарядталатын бірліктер үздіксіз тұтынылатын жағдайларда қолданылады, мысалы, байттарды жүктеу/жолдау үшін төлемақы.
A session based credit control process uses several interrogations which may include first, intermediate and last interrogation. During interrogation money is reserved from the user account. Session based charging is typically used for scenarios where the charged units are continuously consumed, e. g. charging for bytes upload/download.
Оқиғаға негізделген алым
Оқиғаға негізделген несиелік бақылау процесі төлем механизмі ретінде оқиғаларды пайдаланады. Оқиғаға негізделген төлем әдетте бірліктер үздіріссіз қолданылмаған жағдайларда қолданылады, мысалы, пайдаланушы MMS жібергенде.
An event based credit control process uses events as charging mechanism. Event based charging is typically used when units are not continuously consumed, e. g. a user sending an MMS.
Командалық кодтар
Диаметр арқылы кредиттік бақылауды қолдау үшін екі Диаметр хабары бар: CCR (Кредиттік бақылау сұранысы) және CCA (Кредиттік бақылау жауабы). CCR/CCA командасының коды RFC 4006 стандартында көрсетілгендей 272 болып табылады.
In order to support Credit Control via Diameter, there are two Diameter messages, the CCR (Credit Control Request) and the CCA (Credit Control Answer). Command Code for CCR/CCA is 272, as defined in RFC 4006
Квота басқару үшін клиент серверге бірліктерді сұрап және тұтынуды хабарлап CCR жібереді. Сервер бірліктерді береді және пайдаланушыдан төлем қабылдайды. Қарапайым дебет/кредит операциялары үшін клиент серверден пайдаланушының шотын кредиттеу/дебеттеуді сұрап CCR жібереді. Баға туралы сұраныс үшін клиент серверден бірлік бағасын сұрайды, ал сервер бағамен жауап береді.
For quota management the client sends CCR to the server requesting units and reporting consumption. The server grants units and charges the user. For simple debit/credit the client sends a CCR asking the server to credit/debit the user's account. For price inquiries the client ask the server what the price for a unit is, and the server responds with the price.
Хабар ағындары
Хабар ағындары, әдетте, бірліктерді сұраған бақылау нүктесі және оларды сервер бергенімен басқарылады. Хабарламаны NASREQ (RFC4005) сияқты басқа Diameter қолданбалары да құрауы мүмкін, мысалы, уақыт/пайдалану шектеулі сессиялар үшін. Төмендегі диаграмма квоталар арқылы сессия үшін хабарлама ағынының қарапайымдалған нұсқасын көрсетеді. Клиент серверден 10 бірлікті сұраумен бастайды. Сервер пайдаланушының/абоненттің жеткілікті қаражаты барын тексереді. Бұл мысалда сервер клиентке сұралған барлық бірлікті береді. Егер абоненттің балансы жеткіліксіз болса, сервер одан аз бірлікті бере алатын немесе тіпті бас тарта алатын еді. Абоненттік сессия берілген бірліктерді пайдаланғаннан кейін немесе одан бұрын, клиент серверге қанша бірлік пайдаланылғанын және осы жолы қанша бірлік беруді қалайтынын хабарлап, жаңарту жібереді. Клиентке сервермен байланыс кезінде абоненттік сессияны тоқтатуды болдырмау үшін, алдыңғы берілген бірліктер толық пайдаланылмастан бұрын бірліктерді сұрауға рұқсат етіледі. Мысалда клиент, бұрын берілген 10 бірліктің 7-сі пайдаланылған кезде сұрау жібереді; және тағы 10 бірлік сұрайды, оларды сервер береді. Сервер абоненттің балансын төмендету үшін пайдаланылған бірліктер санын пайдалана алады (бірліктерді беру олардың пайдаланылатынын білдірмейді. Пайдаланылған бірліктер AVP-да көрсетілген нақты пайдалану). Сервер берілген бірліктің қанша уақытқа дейін жарамды екенін клиентке хабарлай алады, онда клиент берілген уақыт аяқталғанда жаңарту жіберуі керек. Сессия кезінде көптеген жаңарту хабарламалары болуы мүмкін. Соңында абонент сессияны аяқтайды, ал клиент соңғы пайдаланылған бірліктер туралы ақпаратты қамтитын серверге тоқтату туралы хабарлама жібереді. Сервер осы тоқтату хабарламасын пайдаланып, арнайы резервтерді тазарта алады. Егер абонент сессияны өзі тоқтатпаса, бірақ балансын толық жұмсап қойса, онда сервер жаңарту хабарламасына ертерек бас тартумен жауап беріп, клиентке/бақылау нүктесіне трафикті қайта бағыттауды ұсынуы мүмкін (бұл әдетте тек HTTP/WAP трафигі үшін ғана мағыналы).
The message flows are in general driven by the control point asking for units and the server granting them. The message may also be generated by other diameter applications, such as NASREQ (RFC4005) for sessions that are time/usage limited. The following diagram shows a simplified message flow for a session using quota grants. The client starts by requesting 10 units from the server. The server verifies that the user/subscriber has enough balance for it. In this example the server grants the client all the units it requested. if the subscriber had insufficient balance it could have granted less units or rejected it completely. When or before the subscriber session has used the granted units the client sends an update to the server telling it how many units have been used and how many it would like granted this time. The client is allowed to request units before the previous grant is completely used, in order to avoid suspending the subscriber session while talking to the server. In this example the client sends the request when 7 units of the 10 previously granted units have been used; and ask for 10 more units, which the server grants. The server can use the used units count for debiting the subscriber balance (granting units does not indicate that they will be used. The Used Units AVP contains the actual usage). It is also possible for the server to tell the client how long the grant is valid, in which case the client is expected to send an update when the grant timer expires. There can be many update messages during a session. Finally, the subscriber has ended the session, and the client sends a termination message to the server containing the last Used Units. The server can use the termination message to clear any related reservations made in the back end balance management system. If the subscriber did not terminate the session himself but instead depleted his balance then the server would have responded earlier with reject to an update message, possibly telling the client/control point to redirect traffic (this normally only makes sense for HTTP/WAP traffic).