Diameter协议在电信行业的应用：实时信用控制与3GPP DCC

需积分: 9 71 浏览量更新于2024-06-30 收藏 131KB PDF 举报

"本文档描述了3GPP协议和Diameter Credit-Control Application (DCC)协议在电信行业的应用，特别是关于GSU POOL中的大并发多Radio Gateway (RG)数据业务的预留和处理场景。" 在3GPP协议框架下，Diameter协议是一种重要的核心网络信令协议，用于替代旧的Radius协议，以支持更复杂、更安全的计费、认证和授权功能。Diameter协议被广泛应用于移动通信系统，如3G、4G以及演进到5G的过程中。Diameter协议家族包括多个应用，其中一个就是DCC协议，它专门用于实时信用控制。 DCC协议，如RFC4006所述，定义了一个Diameter应用，可用于实施各种终端用户服务的实时信用控制，包括网络访问、Session Initiation Protocol (SIP)服务、消息服务和下载服务。这个协议对于电信运营商来说至关重要，因为它允许对用户的使用情况进行精确计费和流量管理，确保服务的可持续性和公平性。在描述GSU POOL大并发多RG数据业务时，我们关注的是如何有效地处理大量同时在线用户的数据需求。GSU POOL（Generic Switching Unit Pool）可能指的是一个共享资源池，其中包含多个Radio Gateways，这些RG负责处理来自无线网络的用户数据流量。当有大量用户同时进行数据活动时，DCC协议确保了对每个用户服务的信用控制，如数据用量限制、计费周期和超额使用的处理策略。 1.1 Requirements Language部分定义了文档中使用的规范词汇，确保在讨论技术需求时的准确性和一致性。 1.2 Terminology部分列出了协议相关的术语，帮助读者理解文档内容。 1.3 Advertising Application Support讨论了如何在系统中宣告DCC应用的支持，以便网络节点之间能正确交互。 2. Architecture Models章节可能涉及不同的网络架构模型，这些模型展示了Diameter服务器和代理如何与RG和其他网络组件协作，以执行信用控制。 3. Credit-Control Messages章节详细介绍了DCC协议中的两个关键消息类型： - 3.1 Credit-Control-Request (CCR) Command：这是由服务提供商发起的请求，用于获取或更新用户会话的信用信息，包括预付费和后付费的信用信息。 - 3.2 Credit-Control-Answer (CCA) Command：是响应CCR的命令，包含了服务提供商对信用控制请求的决策，例如是否批准会话继续、剩余信用额度、或需要进行的计费更新。这些消息的交换确保了在高并发环境下，每个RG都能根据用户的信用状态和服务级别协议(SLA)来提供服务，从而优化网络资源的使用并维护服务质量。 DCC协议在3GPP环境中的应用，特别是在处理大并发多RG数据业务时，是确保电信服务质量和经济效率的关键组成部分。通过实时信用控制，运营商能够有效管理网络容量，避免过载，并为用户提供透明且公平的计费体验。

RFC 4006 Diameter Credit-Control Application August 2005

If independent credit-control of multiple services is used, the

validity-time and final-unit-indication SHOULD be present either in

the Multiple-Services-Credit-Control AVP(s) or at command level as

single AVPs. However, the Result-Code AVP MAY be present both on the

command level and within the Multiple-Services-Credit-Control AVP.

If the Result-Code on the command level indicates a value other than

SUCCESS, then the Result-Code on command level takes precedence over

any included in the Multiple-Services-Credit-Control AVP.

The credit-control client MUST indicate support for independent

credit-control of multiple services within a (sub-)session by

including the Multiple-Services-Indicator AVP in the first

interrogation. A credit-control server not supporting this feature

MUST treat the Multiple-Services-Indicator AVP and any received

Multiple-Services-Credit-Control AVPs as invalid AVPs.

If the client indicated support for independent credit-control of

multiple services, a credit-control server that wishes to use the

feature MUST return the granted units within the Multiple-Services-

Credit-Control AVP associated to the corresponding service-identifier

and/or rating-group.

To avoid a situation where several parallel (and typically also

small) credit reservations must be made on the same account (i.e.,

credit fragmentation), and also to avoid unnecessary load on the

credit-control server, it is possible to provide service units as a

pool that applies to multiple services or rating groups. This is

achieved by providing the service units in the form of a quota for a

particular service or rating group in the Multiple-Services-Credit-

Control AVP, and also by including a reference to a credit pool for

that unit type.

The reference includes a multiplier derived from the rating

parameter, which translates from service units of a specific type to

the abstract service units in the pool. For instance, if the rating

parameter for service 1 is $1/MB and the rating parameter for service

2 is $0.5/MB, the multipliers could be 10 and 5 for services 1 and 2,

respectively.

If S is the total service units within the pool, M1, M2, ..., Mn are

the multipliers provided for services 1, 2, ..., n, and C1, C2, ...,

Cn are the used resources within the session, then the pool credit is

exhausted and re-authorization MUST be sought when:

C1*M1 + C2*M2 + ... + Cn*Mn >= S

Hakala, et al. Standards Track [Page 19]

RFC 4006 Diameter Credit-Control Application August 2005

The total credit in the pool, S, is calculated from the quotas, which

are currently allocated to the pool as follows:

S = Q1*M1 + Q2*M2 + ... + Qn*Mn

If services or rating groups are added to or removed from the pool,

then the total credit is adjusted appropriately. Note that when the

total credit is adjusted because services or rating groups are

removed from the pool, the value that need to be removed is the

consumed one (i.e., Cx*Mx).

Re-authorizations for an individual service or rating group may be

sought at any time; for example, if a 'non-pooled' quota is used up

or the Validity-Time expires.

Where multiple G-S-U-Pool-Reference AVPs (section 8.30) with the same

G-S-U-Pool-Identifier are provided within a Multiple-Services-

Credit-Control AVP (section 8.16) along with the Granted-Service-Unit

AVP, then these MUST have different CC-Unit-Type values, and they all

draw from the credit pool separately. For instance, if one

multiplier for time (M1t) and one multiplier for volume (M1v) are

given, then the used resources from the pool is the sum C1t*M1t +

C1v*M1v, where C1t is the time unit and C1v is the volume unit.

Where service units are provided within a Multiple-Services-Credit-

Control AVP without a corresponding G-S-U-Pool-Reference AVP, then

these are handled independently from any credit pool and from any

other services or rating groups within the session.

The credit pool concept is an optimal tool to avoid the over-

reservation effect of the basic single quota tariff time change

mechanism (the mechanism described in section 5.1.1). Therefore,

Diameter credit-control clients and servers implementing the

independent credit-control of multiple services SHOULD leverage the

credit pool concept when supporting the tariff time change. The

Diameter credit-control server SHOULD include both the Tariff-Time-

Change and Tariff-Change-Usage AVPs in two quota allocations in the

answer message (i.e., two instances of the Multiple-Services-Credit-

Control AVP). One of the granted units is allocated to be used

before the potential tariff change, while the second granted units

are for use after a tariff change. Both granted unit quotas MUST

contain the same Service-Identifier and/or Rating-Group. This dual

quota mechanism ensures that the overall reported used units would

never exceed the credit reservation. The Diameter credit-control

client reports both the used units before and after the tariff change

in a single instance of the Multiple-Services-Credit-Control AVP.

Hakala, et al. Standards Track [Page 20]

RFC 4006 Diameter Credit-Control Application August 2005

The failure handling for credit-control sessions is defined in

section 5.7 and reflected in the basic credit-control state machine

in section 7. Credit-control clients and servers implementing the

independent credit-control of multiple services in a (sub-)session

functionality MUST ensure failure handling and general behavior fully

consistent with the above mentioned sections, while maintaining the

ability to handle parallel ongoing credit re-authorization within a

(sub-)session. Therefore, it is RECOMMENDED that Diameter credit-

control clients maintain a PendingU message queue and restart the Tx

timer (section 13) every time a CCR message with the value

UPDATE_REQUEST is sent while they are in PendingU state. When

answers to all pending messages are received, the state machine moves

to OPEN state, and Tx is stopped. Naturally, the action performed

when a problem for the session is detected according to section 5.7

affects all the ongoing services (e.g., failover to a backup server

if possible affect all the CCR messages with the value UPDATE_REQUEST

in the PendingU queue).

Since the client may send CCR messages with the value UPDATE_REQUEST

while in PendingU (i.e., without waiting for an answer to ongoing

credit re-authorization), the time space between these requests may

be very short, and the server may not have received the previous

request(s) yet. Therefore, in this situation the server may receive

out of sequence requests and SHOULD NOT consider this an error

condition. A proper answer is to be returned to each of those

requests.

5.2. First Interrogation

When session based credit-control is required (e.g., the

authentication server indicated a prepaid user), the first

interrogation MUST be sent before the Diameter credit-control client

allows any service event to the end user. The CC-Request-Type is set

to the value INITIAL_REQUEST in the request message.

If the Diameter credit-control client knows the cost of the service

event (e.g., a content server delivering ringing tones may know their

cost) the monetary amount to be charged is included in the

Requested-Service-Unit AVP. If the Diameter credit-control client

does not know the cost of the service event, the Requested-Service-

Unit AVP MAY contain the number of requested service events. Where

the Multiple-Services-Credit-Control AVP is used, it MUST contain the

Requested-Service-Unit AVP to indicate that the quota for the

associated service/rating-group is requested. In the case of

multiple services, the Service-Identifier AVP or the Rating-Group AVP

within the Multiple-Services-Credit-Control AVP always indicates the

service concerned. Additional service event information to be rated

Hakala, et al. Standards Track [Page 21]

RFC 4006 Diameter Credit-Control Application August 2005

MAY be sent as service specific AVPs or MAY be sent within the

Service-Parameter-Info AVP at command level. The Service-Context-Id

AVP indicates the service specific document applicable to the

request.

The Event-Timestamp AVP SHOULD be included in the request and

contains the time when the service event is requested in the service

element. The Subscription-Id AVP SHOULD be included to identify the

end user in the credit-control server. The credit-control client MAY

include the User-Equipment-Info AVP so that the credit-control server

has some indication of the type and capabilities of the end user

access device. How the credit-control server uses this information

is outside the scope of this document.

The credit-control server SHOULD rate the service event and make a

credit-reservation from the end user's account that covers the cost

of the service event. If the type of the Requested-Service-Unit AVP

is money, no rating is needed, but the corresponding monetary amount

is reserved from the end user's account.

The credit-control server returns the Granted-Service-Unit AVP in the

Answer message to the Diameter credit-control client. The Granted-

Service-Unit AVP contains the amount of service units that the

Diameter credit-control client can provide to the end user until a

new Credit-Control-Request MUST be sent to the credit-control server.

If several unit types are sent in the Answer message, the credit-

control client MUST handle each unit type separately. The type of

the Granted-Service-Unit AVP can be time, volume, service specific,

or money, depending on the type of service event. The unit type(s)

SHOULD NOT be changed within an ongoing credit-control session.

There MUST be a maximum of one instance of the same unit type in one

Answer message. However, if multiple quotas are conveyed to the

credit-control client in the Multiple-Services-Credit-Control AVPs,

it is possible to carry two instances of the same unit type

associated to a service-identifier/rating-group. This is typically

the case when a tariff time change is expected and the credit-control

server wants to make a distinction between the granted quota before

and after tariff change.

If the credit-control server determines that no further control is

needed for the service, it MAY include the result code indicating

that the credit-control is not applicable (e.g., if the service is

free of charge). This result code at command level implies that the

credit-control session is to be terminated.

The Credit-Control-Answer message MAY also include the Final-Unit-

Indication AVP to indicate that the answer message contains the final

Hakala, et al. Standards Track [Page 22]

RFC 4006 Diameter Credit-Control Application August 2005

units for the service. After the end user has consumed these units,

the Diameter credit-control-client MUST behave as described in

section 5.6.

This document defines two different approaches to perform the first

interrogation to be used in different network architectures. The

first approach uses credit-control messages after the user's

authorization and authentication takes place. The second approach

uses service specific authorization messages to perform the first

interrogation during the user's authorization/authentication phase,

and credit-control messages for the intermediate and final

interrogations. If an implementation of the credit-control client

supports both the methods, determining which method to use SHOULD be

configurable.

In service environments such as the Network Access Server (NAS), it

is desired to perform the first interrogation as part of the

authorization/authentication process for the sake of protocol

efficiency. Further credit authorizations after the first

interrogation are performed with credit-control commands defined in

this specification. Implementations of credit-control clients

operating in the mentioned environments SHOULD support this method.

If the credit-control server and AAA server are separate physical

entities, the service element sends the request messages to the AAA

server, which then issues an appropriate request or proxies the

received request forward to the credit-control server.

In other service environments, such as the 3GPP network and some SIP

scenarios, there is a substantial decoupling between

registration/access to the network and the actual service request

(i.e., the authentication/authorization is executed once at

registration/access to the network and is not executed for every

service event requested by the subscriber). In these environments,

it is more appropriate to perform the first interrogation after the

user has been authenticated and authorized. The first, the

intermediate, and the final interrogations are executed with credit-

control commands defined in this specification.

Other IETF standards or standards developed by other standardization

bodies may define the most suitable method in their architectures.

5.2.1. First Interrogation after Authorization and Authentication

The Diameter credit-control client in the service element may get

information from the authorization server as to whether credit-

control is required, based on its knowledge of the end user. If

credit-control is required the credit-control server needs to be

contacted prior to initiating service delivery to the end user. The

Hakala, et al. Standards Track [Page 23]

RFC 4006 Diameter Credit-Control Application August 2005

accounting protocol and the credit-control protocol can be used in

parallel. The authorization server may also determine whether the

parallel accounting stream is required.

The following diagram illustrates the case where both protocols are

used in parallel and the service element sends credit-control

messages directly to the credit-control server. More credit-control

sequence examples are given in Annex A.

Diameter

End User Service Element AAA Server CC Server

(CC Client)

| Registration | AA request/answer(accounting,cc or both)|

|<----------------->|<------------------>| |

| : | | |

| Service Request | | |

|------------------>| | |

| | CCR(Initial,Credit-Control AVPs) |

| +|---------------------------------------->|

| CC stream|| | CCA(Granted-Units)|

| +|<----------------------------------------|

| Service Delivery | | |

|<----------------->| ACR(start,Accounting AVPs) |

| : |------------------->|+ |

| : | ACA || Accounting stream |

| |<-------------------|+ |

| : | | |

| | CCR(Update,Used-Units) |

| |---------------------------------------->|

| | | CCA(Granted-Units)|

| |<----------------------------------------|

| : | | |

| End of Service | | |

|------------------>| CCR(Termination, Used-Units) |

| |---------------------------------------->|

| | | CCA |

| |<----------------------------------------|

| | ACR(stop) | |

| |------------------->| |

| | ACA | |

| |<-------------------| |

Figure 2: Protocol example with first interrogation after user's

authorization/authentication

Hakala, et al. Standards Track [Page 24]

剩余56页未读，继续阅读

guoxi780692431

粉丝: 46
资源: 23

Diameter协议在电信行业的应用：实时信用控制与3GPP DCC

3GPP相关的协议详细介绍

3GPP协议

3gpp协议，好资料

3gpp协议

关于sms 业务的3gpp协议

3GPP.rar_3GPP_3GPP协议

3Gpp.rar_3GPP_3GPP协议

3gpp标准 3GPP协议中文版

最新3GPP协议射频协议

36401协议,3GPP协议

最新资源