4.1 Implementation of Time Wheel
Figure 4-1 Model of our timer module
Figure 4-1 shows the design model of the time wheel. We provide three APIs for the user thread. At least two threads are activated after the user calls the VoipTimerInit routine. One of them executes the Tick function every 100ms, the other execute the TimerEventProc.
Following explains the function of each routine.
z VoipTimerInit：Initialize the timer module.
z VoipTimerSet：Add a timer event into the time wheel data structure.
z VoipTimerClean：Delete a timer even from the time wheel data structure.
z Tick：Update the time wheel data structure, and check if there are timer events expired. Move the expired timer events to the event pool. A single thread running across this function.
z TimerEventProc：Retrieve the expired timer event from the event pool and invoke the call back function specified by the user. Multithreads running across this function.
z Call back function：The expiry action that should be performed when the timer is
expired.
4.2 Implementation of Authentication Server
Figure 4-2 State diagram of each transaction in the authentication server
Figure 4-2 shows the state diagram of each transaction in the authentication server which regards the SIP REGISTER message as a request for authentication procedure.
1. When receiving a REGISTER message, the authentication server sends a 401 response to the client and the state changes to RegisterUnauth. The REGISTER message may be retransmitted by the client if the 401 response is lost. The state RegisterUnauth is designed to process these retransmissions of REGISTER.
2. After timer A expired, the state will change to ReferAS which retransmit a SIP REFER to the client until receiving a response. If the authentication server has not received the response after time C expired, the transaction will be terminated. The state WaitNotify is used to wait a NOTIFY sent from the client. The NOTIFY indicates that the client
have already placed the GSM call after receiving the REFER. The NOTIFY should be sent before the expiration of timer D, if not, the transaction will be terminated too.
3. Upon the authentication server receives the NOTIFY in time, it will generate a ticket for the client and enter the next state AuthComplete which will automatically jump to Terminate after timer F expired.
4. In addition, if the client just wishes to renew the old ticket, it will show its old one in the REGISTER message. After verification the ticket, the state will become AuthComplete directly. In this case, the authentication server will handle the retransmission of REGISTER until the timer F expired.
4.3 Implementation of Payment Server
Figure 4-3 State diagram of credit transfer
The Figure 4-3 illustrates the state diagram of credit transfer service. The bold and italic word means that the message is sent to or received from the payee and the normal form is for the payer.
1. After authenticating the request of credit transfer, the payment server simply check the balance of the payer and check if the payee is registered to the system. If balance is
not enough, a 400 response will be sent to the payer, else if the payee is not found, the payment server sends a 404 response to the payer.
2. After transferring the credit from payer to the payee, the request will be forwarded to payee. A 408 response will be sent back to the payer if timer A is expired. In this case, it indicates that the payee is not online and this exception must be handled.
Figure 4-4 State diagram of anonymous event charging and charged by time
The figure 4-4 illustrates the state diagram of anonymous event charging and charged by time service. The bold and italic word means that the message is sent to or received from the consumer and the normal form is for the merchant.
1. After the payment server receives a request for event charging or charged by time, it simply checks if the consumer is registered or not, if not, the payment server will inform the merchant by a 404 response.
2. Otherwise the payment server forwards the request to the consumer and enters the WaitConfirm state. In the WaitConfirm state, the payment server listens to the 1xx response sent from the consumer and processes the retransmission of request. Besides, a timer A will be used to wait the confirmation from the consumer.
3. The transaction will enter the WaitACK state as receiving the 200 response from the
consumer. There are two kinds of transition path of at this point. If the whole transaction is event charging, the state will be changed to the Complete state when an ACK arrived. Otherwise, the state will be changed to the WaitBYE state and a timer C will be started. The calculation of timer C is base on the credit of the consumer and the charging ratio of the transaction.
4. As the payment server receives a BYE message, it will forward the BYE to the opposite DMD but the state remained unchanged. Until the payment server receives a 200 response from the opposite DMD, the state will be changed to the Complete which will become Terminate automatically.
4.4 Measurement of Payment Server
4.4.1 Environment
Figure 4-5 depicts our environment to measure the system capacity of the payment server.
In which all message are transferred on the Ethernet to reduce the effect of network. The protocol is UDP. We put two SIM-DMDs that simulate the real DMD in use. One behaves as the payer and sends credit transfer request periodically to the payment server. The other behaves as the payee and reply a confirmation as receiving a request forwarded by the payment server.
Figure 4-5 Layout of our environment
4.4.2 Measurements
We use Sim-DMD to simulate the users that can send request to the payment server simultaneously. There are 1000 uniform distributed requests for each test. A request is
considered as successful one if the payer receives a corresponding response forwarded from the payment server.
We measure the average processing time of successful request and the success probability of each test in different arrival rate which means the quantity of request received by the payment server per minute. We change the arrival rate for each test. The lower arrival rate means the delay between each request is longer. Table 4-1 shows the result of our test. In this table, we could obtain the system capacity at a given success rate and average processing time from the result. Figure 4-6 plots the curve of the result. From the result, we can obtain a threshold of 1600 (reqs/min.) for which performance becomes worse (lower than 90%) if the arrival rate is higher than the threshold.
Table 4-1 Result of our measurement
Figure 4-6 Curves of the result