Title:	Charging Mechanism for Packet Switched (IP) domain
Date:	99-04/19-21
Source:	NTT DoCoMo
Related to:	23.20
1. Introduction
In the last S2 meeting, it was agreed that volume based charging should be supported in UMTS phase 1 specification. This is shown in the added sentence of 23.20 in the previous meeting as follows. 
“Any problems within the UTRAN which cause loss of data addressed to a UE shall be indicated to the #G-SGSN to maintain the conformance of the data volume counted by the 3G-SGSN with the successfully transferred data volume. It is FFS whether this mechanism provides a degree of conformance required for volume dependent charging.”
 In the above sentence, the mechanism matching the requirement of  volume based charging is still open to be discussed (FFS). In this contribution, it is shown that the mechanism that RNC notifies 3G-SGSN of any problem within the UTRAN which causes loss of data addressed to a UE seems to have problem from the conformance requirement point of view. Then, some alternatives are proposed as the realization of volume based charging and are evaluated.

2. The evaluation of currently proposed mechanism from conformance point of view

 The mechanism currently proposed, which  RNC notifies 3G-SGSN that any problems within the UTRAN which causes loss of data addressed to a UE is shown Fig.3 

 This mechanism is clarified as follows;
 First, SGSN counts data when SGSN sends data to RNC. Then, if RNC can not send data to UE completely, RNC notifies SGSN that data can not be received by UE completely and SGSN discount the data volume.

SGSN

RNC

UE

PDU

PDU

RLC Ack

PDU

PDU

RLC Ack T.O.

NAK

Count

PDU

data

PDU

data

Discount

[ + x ]

Count

[ + y ]

[ - y ]

Figure 3

 But in this mechanism, since it is hard to report that data loss is occurred in the transmission layer level, over counting for charging is occurred when the data are lost within Iu transmission at the transmission layer level in the congestion or equipment failure condition  (Fig.4 and Fig.5). 

SGSN

RNC

UE

PDU

PDU

Count

PDU

data

PDU

data

[ + x ]

Count

[ + y ]

Figure 4

SGSN

RNC

UE

PDU

PDU

RLC Ack T.O.

NAK

Count

PDU

data

PDU

data

[ + x ]

Count

[ + y ]

PDU

NAK

PDU

RLC Ack T.O.

Figure 5

 Consequently the proposed mechanism can not exactly support volume based charging. And one another demerit of this method is functionality redundancy for counting between RNC and SGSN. This is because that RNC  need to count data volume for the preparation of failure reporting as well as SGSN. So in the next chapter, some alternatives are proposed.

4. Alternatives

Method 1 : Light LLC
　There is Protocol layer between UE and SGSN that report of acknowledgement to SGSN when UE received the data. And SGSN charge the data which receive the acknowledgement.

SGSN

RNC

UE

PDU

PDU

RLC Ack

Ack

Ack

RLC Ack

Count

PDU

RLC Ack T.O.

T.O.

data

PDU

data

PDU

data

[ + x ]

PDU

data

Figure 6

Method 2 : There is protocol layer between RNC and SGSN. RNC notifies SGSN of acknowledgement  when UE received the data by this protocol. And SGSN charge the data which receive the acknowledgement.

SGSN

RNC

UE

PDU

RLC Ack

PDU

PDU

RLC Ack T.O.

NAK

Count

PDU

data

Ack

PDU

PDU

data

[ + x ]

Figure 7

Method 3 : RNC has a function of counter. 
 First, RNC count data, and any time when SGSN needs to know its counter, RNC notified its counter’s value to SGSN. It is noted that in this method, still SGSN has the functionality of charging ( for example, making charging bill data format and interface to charging gateway function (CGF))

SGSN

RNC

UE

PDU

PDU

PDU

RLC Ack

PDU

PDU

PDU

RLC Ack T.O.

Notification counter [ x+... ]

Clear

Count 

[ + x ] 

Figure 8

5.Cpmparison
　
Method 1, 2, and 3 are evaluated in the following table.

	Method 1	Method 2	Method 3	
Merit	RNC needs no function of charging	SGSN can know whether the data must be counted or not by each packet.
	There are small number of signal between SGSN and RNC compared with other alternatives.
SGSN does not need counting function.
	
Demerit

	Numbers of signals are increase in the air interface.
L2 link is necessary than RLC.	There are large number of signal between SGSN and RNC compared with other alternatives.

Valuation	No good	No good	Good	

 In result of above table, method 3 is the most valuable. It is also clarified that even in the SRNS relocation over charging does not occur since RNC does not count the data which it does not receive the acknowledgement.

6.Conclusion
It is clarified that the current proposed method can not match the requirement of conformance. Then, some alternatives are proposed as the realization of volume based charging and are evaluated. As the result, for volume based charging in packet switched (IP) service domain, it is clarified that the best method is that RNC have a function of counting and notifies SGSN counted volume. 

7.Proposal

It is proposed to add the following sentences to 23.20 to the chapter “9.8.3 Iu reference point - User plane towards IP domain“ or “9.12 Others” under a headline “Reliable Iu packet bearer”

“In IP domain, successfully transferred data volume addressed to UE are temporally counted by RNC and are notified to 3G-SGSN any time when 3G-SGSN needs them.”