This appendix describes the discrete event simulation model for the credit pre-reservation mechanism (CPM). The simulation defines four types of events to represent a new session arrival (S arrival), a packet arrival for a session (P arrival), a CCR message delivery (CCR), and a CCA message delivery (CCA). Both the CCR and the CCA have three sub-types: “INI-TIAL REQUEST”, “UPDATE REQUEST”, and “TERMINATE REQUEST”. In a simulation run, the events are inserted into an event list and are removed (and processed) from the list in the increasing timestamp order.
An event e has a field e.s that represents the session of this event. Several variables are used to calculate the output measures B, W , Pr, Pnc, and Xsin a simulation run, including:
• nb: the number of buffered packets
• nl: the number of the LC periods where more than one RU operation is executed
• np: the number of packet arrivals
• nr: the number of RU operations executed
• ns: the number of session arrivals
• Nb: the number of blocked session requests due to insufficient credit units
• Nf: the number of force-terminated sessions due to insufficient credit units
• Nl: the number of LC periods
• T : the summation of the waiting times for all buffered packets
From the above variables, we compute the following output measures:
B = nb nr
, W = T np
, Pr = nl Nl
, Pnc = Nb+ Nf ns
, and Xs = nr ns
The following variables are also used in the simulation:
• Cr: the amount of the remaining credit in a user account at the OCS
• Na: the number of currently active sessions
• s.c: the amount of remaining allocated credit units at session s
• s.nb: the number of currently buffered packets at session s
Figure A.1 illustrates the flowchart of the simulation model (Steps 1-21). It contains two modules: the CCR and the CCA modules shown in Figures A.2 (Steps 22-30) and A.3 (Steps 31-44), respectively. The simulation terminates when the total credit depletes (i.e., when Cr < θ) and all existing sessions are completed. The details are described as follows:
Set initial values, and create the event list;
Generate the first S_arrival event and insert it into the event list
e.type?
Generate a CCR (INITIAL_REQUEST) event;
Generate the next S_arrival event S_arrival
Figure A.1: Flowchart of the simulation model for the CPM
Steps 1-2. The initial values (e.g., Cr, Na, Ns, etc.) are set up. The event list is set empty. The first S arrival event is generated and inserted into the event list.
Steps 3-4. The next event e is removed from the event list. This event is executed based on its event type.
Steps 5-6. [e.type=S arrival] A CCR (INITIAL REQUEST) event and the next S arrival event are generated and inserted into the event list. The Ns value is increased by one. The simulation proceeds to Step 3.
Step 7. [e.type=CCR] The CCR module in Figure A.2 is executed. This module is used to process the CCR message (see Steps 22-30).
Step 8. If there is no active sessions (i.e., Na= 0; which implies that Cr < θ and the event list is empty), the statistics (B, W, Pr, Pncand Xs) are calculated, and the simulation terminates.
Otherwise, the simulation proceeds to Step 3.
Step 9. [e.type=CCA] The CCA module in Figure A.3 is executed. This module is used to process the CCA message (see Steps 31-44).
Steps 10-11. [e.type=P arrival] Np is increased by one. The simulation generates a random number R (where 0 < R < 1) to determine whether the arrival packet is the last one or not. If R > α (the packet is not the last one), Step 12 is executed. Otherwise, Step 19 is executed.
Step 12. The next P arrival event for session e.s is generated and inserted into the event list according to the increasing timestamp order.
Step 13. If s has some credit units (i.e., s.c > 0), Step 14 is executed. Otherwise, Step 18 is executed.
Step 14. The s.c value is decreased by one (i.e., the arrived packet is successfully processed).
Step 15. If s.c equal to the threshold value δ (i.e., s.c = δ), Step 16 is executed to reserved more credit units. Otherwise, Step 3 is executed.
Step 16. If R > α, and if the previous CCR message has successfully reserved credit, Step 17 is executed. Otherwise (session is terminated), there is no need to send the CCR message, and the simulation directly proceeds to Step 3.
Step 17. A CCR(UPDATE REQUEST) event is generated to request for more credit units. The simulation proceeds to Step 3.
Step 18. If s.c = 0, at Step 13, the arrival packet is buffered and the s.np value is increased by one. The simulation proceeds to Step 3.
Steps 19-21. At Step 11, if the arrived packet is the last one that arrives during the RU op-eration, the CCR(TERMINATE REQUEST) is delayed delivered after the GGSN has received the CCA message (which occurs at Step 36 in Figure A.3). Otherwise, Step 20 generates a CCR(TERMINATE REQUEST) event and inserts the event into the event list. Then the simulation proceeds to Step 13.
Steps 22-29 describe the CCR module.
Step 22. The sub-type of the CCR event is checked and is executed.
Steps 23-25. [subtype=INITIAL REQUEST] If the OCS has enough credit units (i.e., Cr ≥ θ), the Cr value is decreased by θ, the number of the active sessions Nais increased by one, and the CCA(INITIAL REQUEST) event is generated and inserted into the event
no
Figure A.2: Flowchart of the CCR module
list. Then the simulation returns to Step 8 in Figure A.1. If Cr < θ at Step 23, then the new session is rejected, and the CCR module exits without taking any action.
Steps 26-29. [subtype=UPDATE REQUEST] If Cr ≥ θ, then Cr is decreased by the amount θ, and the CCA(UPDATE REQUEST) event is generated and inserted into the event list.
Otherwise, a CCA(UPDATE REQUEST, credit depleted) event is generated and inserted into the event list (i.e. the simulation rejects the CCR). The simulation returns to Step 8 in Figure A.1.
Step 30. [subtype=TERMINATE REQUEST] The session s refunds the credits to the OCS (i.e., Cr← Cr+ s.c). The number of the active sessions Nais decreased by one.
Steps 31-43 describe the CCA module.
Step 31. The sub-type of the CCA event is checked and executed.
delayed
Figure A.3: Flowchart of the CCA module
Step 32. [subtype=INITIAL REQUEST] The first P arrival event e (with the current times-tamp) of session e.s is generated and inserted into the event list.
Step 33. The amount θ of credit units are reserved for session s (i.e., the s.c value is increased by θ).
Step 34. The simulation checks whether the credit of session s suffices to deliver the buffered packets (i.e., s.c ≥ s.nb). If so, Step 35 is executed. Otherwise, Step 38 is executed.
Steps 35-36. [s.c ≥ s.nb] The s.c value is decreased by s.nb, and s.nbis set to 0. If s is delayed termination (Step 21 in Figure A.1), Step 40 is executed. Otherwise, Step 37 is executed.
Step 37. If s.c < δ, Step 39 is executed. Otherwise, the simulation returns to Step 3 in Figure A.1.
Step 39. [s.c < θ] A CCR(UPDATE REQUEST) event is generated and inserted into the event list.
Step 40. A CCR(TERMINATE REQUEST) event is generated and inserted into the event list.
Step 41. [subtype=UPDATE REQUEST] If the CCR event indicates that the credit is de-pleted (Step 29 in Figure A.2), Step 42 is executed. Otherwise, Step 33 is executed.
Steps 42-44. If s.c > 0, the GGSN will continue to deliver the packets until s.c = 0 or s is terminated. Otherwise (s.c = 0), the next P arrival event of s in the event list is removed, the session is terminated, and Nais decreased by one.