4 Service architecture design
4.3.4 Telephony Access
When a user dials the 1 MORE phone number, he is connected to the 1 MORE PCBX.
This PCBX immediately transfers the user to the application controller if there are enough resources available. The application controller checks the validity of the user based on his telephone number. It then starts the dialog, using the speech recognition and synthesis services of the speech server. Depending on the type of service the user requests, a conference is started or the user is connected to another, randomly chosen subscriber.
To be able to attend to the calling users with an acceptable availability rate, satisfying numbers of resources in the PCBX, the application controller and the speech server have to be calculated. For this calculation, the results of the pilot study are used, see section 3.5. Although the behaviour of the pilot members might not be completely representative for the behaviour of actual customers, it is the best information that is available at this point. Once the service is introduced in real life, the number of resources can be revised to adapt the system to the actual situation and to actual user behaviour.
The expected number of users at the end of the first year is 30.000 (see [10]). From the pilot results it is concluded that each user uses the service once a week, for about five minutes, resulting in 30.000 calls to 1 MORE per week. Since the calls are distributed evenly over the weekdays, 30.000/7 = 4286 calls are made every day. 31% of these calls will take place during the peak hours, between 3 and 6 p.m.; i.e. in a period of 3 hours, or 180 minutes, 1329 calls are made. As the calls last for five minutes, this means that on average (1329*5) / 180 = 37 concurrent calls are going on at any time during these peak hours.
To calculate the number of resources that is needed, the distribution function of these calls has to be found. For this purpose, the three-hour period is divided into 36 five-minute periods, To to T35, thus creating a discrete problem. Furthermore, it is assumed that during the peak hours, calls are distributed evenly, i.e. the probability of a call taking place at To is equal to the probability of that taking place at T1 or T35 . Now, the probability that at a certain time Ti, where 0 < i < 35, no users make use of the service is:
P(O) = (--.L)O . (li)\329 . 1329! = (--.L)O . (li)\329 . (1329J
36 36
(1329-0)!xO!
36 360
(4.1 )Or, in general, the probability that k users use the service:
P(k) = (P)' (1- P y-' (;]. n = 1329, P = ,\
(4.2)Equation (4.2) is of course the binomial probability distribution. The binomial distribution approaches the Poisson distribution for large values of n*p. As n*p = 36,9 » 1, the Poisson function can be used to find the distribution:
n
= 1329
, p= --.L
36 ' r 1/=
n . p= 36 9
, (4.3)P.P.S. Giesberts 53/128
ICS/EB 750 1MORE November 2000
This function is shown in Figure 4-7 as the yellow chart. It can be seen that the probability of more than 60 users in period T; is almost zero. As Tj is no different than
h1
or TH, it can be concluded that if 61 users can be served by the system simultaneously, the availability of the system is better than 99,99%!0.07 - , - - - -- - - ,
-o
-,fo-m'1'"l'T""""''''''''''I'"'!'I''I~'''''''''CTTTT':'TTT1rr.,-:-r, -,-:-" T7'"rTT,Tr, ' i T, rn,,;;-;, .- I'TTT1-rr-""TCT1TTr-rrr-Tl- 0~ <0 ,'1- ,(Q
rt
".>~ ".><0 ~ ~q.
<o~ <0<0 ",'1- ",(Q cob'k
Figure 4-7 Probability distribution of number of callers per period Ti
Of course, these results are based on an average use of 1 MORE, similar to that during the pilot period. Therefore, this number only corresponds to the number of Group Call users. In the real life implementation of 1 MORE, Group SMS will probably reduce the numbers of Group Call conversations, decreasing the expected number of n. However, Random Call and Information services will enlarge the number of calling users. To get a view of the dependence of the number of resources on n the calculation was also performed for several other values of n. To achieve a similar degree of availability (99,99%), the numbers of needed resources for each value of n is shown in Figure 4-8. Number of users in three hour period
Figure 4-8 Resources needed to achieve 99,99% availability
To account for all the unknown factors in user behaviour and for estimations in the assumptions that were made, a value of about 2500 for n seems to be a fitting choice. To achieve 99,99% availability, the number of concurrently served users should be equal to 100, see Figure 4-8. Obviously, this number is based on the expected number of subscriber at the end of the first year of operation. As the subscriber-base, hopefully, gradually grows over time, there should be more than enough opportunity to adapt the system to the actual number of users and their behaviour.
54/128 P,P.S. Giesberts
1MORE November 2000
leS/ES 750
To be able to serve 100 users, the Application controller should run 100 interfaces simultaneously. The number of needed speech engines and synthesis objects in the speech server, is more difficult to determine. To be certain of correct performance it could be chosen to set this to 100 as well, but as users connected to the 1 MORE service are mostly interacting with their friends, instead of with the system, thus requiring no speech recognition or synthesis, this is probably much too large. As users can be expected to be interacting with the system for no more than 10-20% of the total connection time, 20 engines should do in principle. However, as users cannot be expected to interact with the system consecutively and to prevent or shorten delays in this interaction, a number of 40 or 50 is a lot safer.
To calculate the number of ISDN lines to the network, first the percentage Group Calls on the total number of calls has to be defined. It is probably in the vicinity of 50%, but to be on the safe side it is chosen to be 75%, resulting in 75 simultaneous Group Calls. The maximum number of conferees is expected to be five, including the initiator, in
accordance with the pilot results. This results in 5*75 is 375 lines to the network. The other 25% of the calls are random calls or information service calls, both accounting for 2 network connections each, or 25*2 = 50 connections in total. Hence, the necessary number of connections to the network is 425. If the Dialogic DMN100-4E1 cards are used, which support 4 ISDN-30 lines or 120 voice-channels each, 4 of these cards have to be inserted in the PCBX, allowing for a total of 480 connections.
If the Dialogic DCB/960SC cards, which support 19 five-party conferences
simultaneously, are used for the conferences, 4 of these cards are needed, allowing for a total of 76 conferences. If the number of parties is four (or three), 4 cards can
accommodate up to 96 (or 128) conferences. The connection between the PCBX and the Application controller can be implemented by 4 ISDN-30 lines with a Dialogic DMN100-4E1 card on each side. The total number of cards in the PCBX is now: 5 Dialogic DMN100-4E1 cards and 4 Dialogic DCB/960SC cards. The network traffic between the application controller and the speech server will maximally consist of about 50 times 64kbitls, or 3,1 Mbitls. Thus, a simple 1 OMbitis network card should suffice, but for future scalability a 1 OOMbitis card is the preferable option. All these numbers are also shown in Figure 4-9.
Figure 4-9 1 MORE resources for telephony access
41SDN-30 connections
Exact numbers of simultaneously used Random Calls cannot be determined from the pilot study results, simply because Random Call was not part of the study. However, it is assumed that maximally 50% of the 100 simultaneous calls to 1 MORE will be of the Random Call type. Assuming an average interaction time of the user with the 1 MORE system of about 20% of the total connecting time, a maximum of about 50% of these calls need a randomise function simultaneously, i.e. 25 randomise engines. As the random profile server is also used by the Random SMS function, a number of 50 randomise threads should be sufficient for the complete service. Of course, the number of actual threads can be made dependent on the number of requests on the random server.
P.P.S. Giesberts 55/128
ICS/EB 750 1MORE November 2000
Furthermore if the server might encounter a period of overload, it can prioritise Random Call request before Random SMS requests, as calls are more sensitive to delays than SMS messages.