5 Use Case Requirements 1.1 Configuring the network User:Network Operator Use scenario: The operator sets up the initial configuration file and boot-up the system. The configuration can be done interactively, or in batch mode in which case there would be several configurations available to the operator. Frequency: done only one time at the system initialization Criticality: How the network is configured is not a critical issue, but it is useful to have more than one ways of configuring the network. 2.1 Report network status User: network monitor Use scenario: Upon the request from the network operator, network monitor reports the network status to the operator Frequency: happens on demand Criticality: This is a necessary feature. 2.2 Gather network status information User: network monitor Use scenario: The network monitor gathers status information of the network periodically. The period is set default at the system boot-up time, but the network operator can change it if necessary. Frequency: happens periodically Criticality: This is a necessary feature. 3.1 Reconfigure the cell User: network operator Use scenario: The network operator sees that cell No.4 has call drop rate higher than threshold value. He/she decides to increase the number of channels that the cell can handle. Criticality: This is a necessary feature. 4.1 Read event and launch it to the network 4.1.1 Get an event and shape it as an event object User: Event Handler Use scenario: The event handler reads events from a file. (Or, from a random number generator which generates events.) Then, it creates an event object according to the event, and send it to the corresponding SM. 4.1.2 Put the event object into the Event Queue User: simulation manager Use scenario: Once getting an event object from the event handler, if the event fire time is not up yet, the SM puts it on to the event queue according to time sequence of the event. Criticality: This is not necessary for simple simulation, but necessary for advanced simulation. 4.2 Dispatch event object User: simulation manager Use scenario: Simulation manager gets an event from the front side of the queue, and dispatches the event object to the corresponding network component (either to the cell or portable?). If the event fire time was up when the event object was received from the Event Handler, the SM dipatches the event object right away. Criticality: This is a necessary feature. (4.2.1 to 4.2.4 are optional use case if the simulation takes care of both the call initiation and call receiving site.) -------------------------- 4.2.1 Call initiation User: portable Use scenario: The portable dials a number and waits for connection. The signal is directed to the cell where the portable belongs. Criticality: This is an optional feature if the simulation only concerns call arrival. 4.2.2 Direct the call User: cell Use scenario: The cell direct the call to a local portable, a portable in other cell which is in the same OMC, or to the one which is in other OMC. Criticality: This is an optional feature if the simulation only concerns call arrival. 4.2.2.1 User: cell User scenario: The cell directs the call to anther cell in the same OMC. The cell first asks its OMC whether the destination portable is registered to it, and get a reference to the cell where the portable is registered to. Then, direct the call to the cell. Criticality: This is an optional feature if the simulation only concerns call arrival. 4.2.2.2 User: cell User scenario: The cell directs the call to a cell in another OMC. The cell first asks its OMC whether the destination portable is registered to it, but it is not, and the OMC broadcasts the destination portable id to other OMCs. The OMC which has the portable will direct the call to the cell where the portable is registered. Criticality: This is not a necessary feature. Depending upon kinds of services, the call may or may not be directed to other OMC. Also, this is an optional feature if the simulation only concerns call arrival. 4.2.3 Receive the call User: portable Use scenario: The portable is ringing, and it is picked up. Since then, the call object is created and live until either side of the portables hangs up. Criticality: This is an optional feature if the simulation only concerns call arrival. 4.2.4 Dispatch call termination event User: simulation manager Use scenario: Simulation manager gets an event from the front side of the queue, and sees it is a call termination event. It dispatches the event to the corresponding portable. The portable disconnects itself and the call object is deleted. By seeing the call object is deleted, the other part of the portable disconnects itself too. Criticality: This is a necessary feature. -------------------------- 4.2.5 Call arrival User: Cell Use scenario: Upon getting the event from the SM, the cell asks the portable if it is in use or not. If it is, the call event is dropped. If it is not, the cell provides a channel for the portable, and creates a call object. 4.2.6 Call termination User: portable Use scenario: Upon getting the event from the SM, the portable terminates the call. The call object is deleted, and the channel is released. Criticality: This is a necessary feature. 4.2.7 Portable move User: Cell Use scenario: Upon getting the event from the SM, the cell first checks if the portable was in use. If yes, and if the destination cell is free of channel, turns the portable over to the destination cell. Then, the original cell releases the channel assigned to the portable, and the new cell allocates a new channel for the portable. If the portable was not in use, the old cell simply drops the portable from its list, and the new cell adds it to its list. Criticality: This is a necessary feature. 5.1 Log the call block User: cell Use scenario: A cell needs to allocate a channel for for a new call or handoff call, but there is no channel available. Then the cell writes the call block information to a log file. Criticality: This is a necessary feature.