We have chosen to write the interpreter in Erlang10. We can today simulate the system, but the interface is textual and based on scripts to describe the scenarios.
The Erlang however is a modern languages and has libraries for graphics linking to Tk.
The intended solution structure presented in Figure 1.1 can now be made concrete as in Figure 1.2. In the concrete version of our goals:
Service builder has been written in Erlang using Erlang/Tk to implement the user interface, although only a first prototype.
Analysis tools will be written in Erlang, PROLOG or even C, with the interface to the other parts and user interface written in Erlang/Tk.
Simulator/Animator has been written in Erlang/Tk.
1.5 CONTRIBUTIONS
We have formally modeled the ITU-T Intelligent Network standard. The model handles the key issues described in Section 1.2.1 in the following way:
structured design
The graphical building blocks style described in the standard, extended with a mechanism to express data flow, enables a structured design.
fidelity of design
The abstract machine style of operational semantics with simple mathemat-ical notation gives an operational mode of modeling. This way of modeling makes the step from the informal standard to the formal model, considering the circumstances, easy.
The model is executable and a tool for executing the model has been written in Erlang.
finding conflicts
Nothing has been done towards the detection of conflicts.
conflict diagnosis
Since no conflicts can be detected other as incorrect or unexpected behaviour of the simulations no diagnosis support has been added.
conflict resolution
The only built in support for conflict resolution is the possibility to give priorities to the services.
10See section 4.3 for a more thorough description of Erlang.
1.5.1 Example design scenario
To illustrate the definition of services in the IN–model we present an example definition of a service, where the basic building blocks defined in IN are used. The building blocks of the IN–model are called Service Independent Building Blocks or SIBs for short. The service definition is presented using the block diagrams suggested in the standard, augmented with a diagram describing the the dynamic data flow of the service and the static instantiation of the building blocks.
The Service is the Automatic Alternative Billing service (AAB) that allows a subscriber to charge an alternative account when placing a call. The service is activated prior to dialing a destination number. The subscriber is queried for the account to which he wants to redirect the charge, and for the appropriate PIN code.
Control
We will first describe the control flow of AAB, shown in diagram in Figure 1.3.
EachSIBis presented as a rectangular box with the mnemonic name of its instance in bold and theSIB type in normal font below. In the two firstSIBs in the chain, theSIBtype name is surrounded by brackets to indicate that they are hierarchical SIBs, defined in a similar way to a service. From eachSIB rectangle emanates a number of arcs representing the possible outcomes of theSIB’s execution (these are logical ends in the vocabulary of the IN standard). TheSIBrectangle in which the arc ends, is the nextSIB in the flow of control.
Return
Clear Call Quit Proceed with New Data POI
analysed Adress
Success Success
[Get_N]
start:AAB
Success
Translate Translate
Error
Charge Success Charge
Control flow:
User Interaction Success Exit
Error No Match
Error Match
Screen Screen Error PIN [Get_N]
Fail Fail Error
Figure 1.3: Example: Control flow in the Automatic alternative billing service
The leftmost arc that does not emanate from aSIBis annotated with the point in the call (Point of Initiation –POI) at which the service is invoked. The rightmost rectangular boxes lack outgoing arcs and represent Points of Return (POR), which like theSIBs have a mnemonic in bold and the type below in normal font.
• The POI for the AAB service is at the point of the call where the address of the call has been analysed; in this case it is not an address to another subscriber but a request for the AAB service.
1.5 Contributions 11
• The FirstSIBis called start:AAB and ofSIBtype Get N, which is a hierar-chical SIB that collects an account number from the subscriber, giving him a number of tries to supply an account in the correct format. The SIB has three logical ends: success, fail or error.
• The PIN SIB is of SIB type Get N as well, and collects the PIN from the user.
• The ScreenSIBis ofSIBtype screen and checks whether the data supplied is found in its screening list, the logical ends are match, nomatch and error.
The logical end error signifies that some internal error has occurred, such that the screening list does not exist.
• The Translate SIB is of SIB type translate converts the account number given by the subscriber to the actual account which can be an external ac-count, e.g., a bank acac-count, to be charged. The translate SIBs logical ends are success or error, where error would typically be the result when there is no correct conversion to be had.
• The Charge SIB of type charge signals the billing system that the charge shall be handled by the service. The only logical end is success and the normal call handling is resumed but with new data.
• The ExitSIBis of type user interaction and informs the subscriber that the service has failed. The service has two logical ends, success and error, but in both cases the call is cleared.
Data
To show the flow of data in the service as seen in Figure 1.3, the SIBs are once again presented as rectangles in the same manner as for the control flow but here the arcs (dotted so that one can superimpose the two diagrams without giving rise to ambiguity) represent the flow of dynamic data between theSIBs. The endpoints of the flows are annotated with the name of the dynamic data, or call instance data (CID) in IN terminology.
In some cases the dynamic data is composed of parts received from several preceding SIBs, as is the case with screen data of the Screen SIB. The h , i conjoining data from the start:AAB and PIN SIBs, the two data flows indicate that the screendata is the tuple constructed from these.
Below the SIBs there is a list of statically instantiated data, or service support data (SSD) in IN terminology.
The statically instantiated data is instantiations of theSIBs performed at the definition of the service; specialising theSIBs for their role in the service. OneSIB may have several different instantiations in the same service, e.g., the Get N SIB which has two different instances in AAB.
Proceed with New Data Return
User Interaction Exit
type:null
annoucement:"AAB failed"
Clear Call Quit PIN
[Get_N]
Translate
Translate Charge
Charge Screen
Screen ssd:<<account, >,nil>
screen:< , >
Data:
sib:Get_N
end:"Too many tries"
error:"Error AAB"
length:4 format:"NNNN"
tries:3 ask:"PIN please"
wrong:"Wrong PIN"
type:pin
no_of_tries:3
list:AAB_PASSWD
type:2 service_feature:aab2 [Get_N]
start:AAB
info:
collected: collected:
translated:
file:AAB_ACCOUNT
new_armed:
new_present:
new_armed:
new_present:
new_armed:
new_present:
sib:Get_N ask:"Account please"
wrong:"Wrong account"
end:"Too many tries"
error:"Error AAB"
type:account length:6 format:"NNNNNN"
no_of_tries:3 tries:3
Figure 1.4: Example: Data flow in the Automatic alternative billing service
Below is explained theSSDof the SIBs in AAB:
• The start:AABSIBbeing a hierarchical Get N SIBhas the following static data:
sib The name of the hierarchical sib, in this case Get N.
ask The question posed to the user.
wrong The answer given a when a string on the wrong format is supplied by the user.
end The answer given to the user when he has made the maximum number of tries.
error The answer given to the user should an internal error occur.
type The type of string expected from the user.
length The length of the string expected from the user.
format The format string expected from the user, e.g. in this case six digits.
number of tries The maximum number of tries allowed.
tries This is the place of the internal counter that keeps track of how many tries have been performed so far.
• The Screen SIB has the following static data:
list The screening list to be used.
• The TranslateSIB has the following static data:
le The translation list to be used.
• The Charge SIBhas the following static data: