Phone event rules
The following rule is applicable when an offhook event has been received from a phone and there are no incoming calls for that phone. A new originatingBCSM is initiated and is added to the set of “Active”BCSMs for this phone.
event: notification(phone, offhook, list: hd(σ)) ∧⊥ list: null(incoming(phone, data))
h running, data, σ, db i id:=create(bcsm,state)
−−−−−−−−−−−−−−→ h running, data0, list: tl(σ), db i (5.1)
where phone = event: sender(list: hd(σ))
state = bcsm : new(O Null, ⊥, phone, true, db) data0 = add active(id, phone, data)
The following rule is applicable when an offhook event has been received from a phone and there are incoming calls for that phone. The first of the Incoming BCSMs is chosen and is added to the Active set as well as notified that an offhook has occured (a message is sent to thatBCSM).
event: notification(phone, offhook, list: hd(σ)) ∧⊥
¬list: null(incoming(phone, data)) h running, data, σ, db i send (m, bcsm id)
−−−−−−−−−−→ h running, data0, list: tl(σ), db i (5.2)
where phone = event: sender(list: hd(σ))
data0 = dequeue incoming(phone, data) bcsm id = list: hd(incoming(phone, data))
m = hhssf, notificationi, offhook, phonei
5.4 Rules 55
The following rule is applicable when an onhook event has been sent from a phone.
Then the SSF sends an onhook message to all BCSMs in the Active and P assive sets of this phone. The Active and P assive sets for this phone are then emptied.
event: notification(phone, onhook, list: hd(σ)) h running, data, σ, db i broadcast (m)
−−−−−−−−→ h running, data0, list: tl(σ), db i (5.3)
where phone = event: sender(list: hd(σ)) ha, p, ii = current bcsms(phone, data)
data0 = clear active passive(phone, data)
m = Sto∈a∪p{hhhssf, notificationi, onhook, ⊥i, toi}
The following rule is applicable when a connect message or service request from the phone has been sent to the SSF. The message is relayed to all active BCSMs for this phone.
event: notification(phone, connect, list: hd(σ)) ∨ event: notification(phone, service, list: hd(σ)) h running, data, σ, db i broadcast (m)
−−−−−−−−→ h running, data, list: tl(σ), db i (5.4)
where m = Sbcsm id∈active{hhhssf, requesti,
event: name(list: hd(σ)) event: data(list: hd(σ))i, bcsm idi}
active = active(event: sender(list: hd(σ)), data)
Connection handling rules
The following rule is applicable when a termination event has been sent from a BCSM. For each path to and from thisBCSMthe path is removed and the BCSMs at the other end are notified of the termination. The terminatedBCSMis removed from the Active, P assive sets and from the Incoming queue.
event: notification(bcsm, terminate, list: hd(σ)) h running, data, σ, db i broadcast (m1∪ m2)
−−−−−−−−−−−−→ h running, data3, list: tl(σ), db i (5.5)
where f rom = event: sender(list: hd(σ)) phone = event: data(list: hd(σ))
prev = previous bcsm(f rom, data) next = next bcsm(f rom, data) data1 = purge(f rom, phone, data)
data2 = remove path(hprev, f romi, data1) data3 = remove path(hf rom, nexti, data2)
m1 = notify({prev, next}, onhook)
m2 = notify phone(phone, data, f rom, terminate)
The following rule is applicable when a connection request from aBCSM has been sent. A new terminating BCSM is initiated and a path is set up with the BCSM requesting a connection.
event: request(bcsm, connect, list: hd(σ)) h running, data, σ, db i id:=create(bcsm,state)
−−−−−−−−−−−−−−→ h running, data0, list: tl(σ), db i (5.6)
where phone = event: data(list: hd(σ)) f rom = event: sender(list: hd(σ))
state = bcsm : new(T Null, f rom, phone, true, db) data0 = add path(hf rom, idi, data)
The following rule is applicable when a connection request from aBCSM has been sent and the facility for connection is not available. This case corresponds to a failure or congestion in the switch. A message is sent to the requesting BCSM informing it of the failure.
event: request(bcsm, connect, list: hd(σ)) h running, data, σ, db i send (m, f rom)
−−−−−−−−−→ h running, data, list: tl(σ), db i (5.7)
where phone = event: data(list: hd(σ)) f rom = event: sender(list: hd(σ))
m = hhssf, notificationi, select fail, phonei
5.4 Rules 57
The following rule is applicable when an authorisation notification has been sent from a BCSM. This signifies that the tests that a user may begin a call has been successful. An example of a test is when the user subscribes to teenline, then the service will during a specified part of the day require that the user supplies a password in order to place an outgoing call. The phone connected to the BCSM, if any, is notified.
event: notification(bcsm, authorised, list: hd(σ)) h running, data, σ, db i broadcast (m)
−−−−−−−−→ h running, data, list: tl(σ), db i (5.8)
where phone = event: data(list: hd(σ)) m = notify({phone}, authorised)
The following rule is applicable when a select facility request has been sent from aBCSM. If the phone is not busy (i.e. the Active, P assive sets and the Incoming queue are empty) a facility available notification. If on the other hand the phone is busy theBCSMis sent a busy notification. Finally theBCSMis entered into the phone’s Incoming queue.
event: request(bcsm, select facility, list: hd(σ)) h running, data, σ, db i send (m, f rom)
−−−−−−−−−→ h running, data0, list: tl(σ), db i (5.9)
where phone = event: data(list: hd(σ)) f rom = event: sender(list: hd(σ)) ha, p, ii = current bcsms(phone, data) f acility =
( facility available if (a ∪ p = ∅) ∧ list: null(i)
busy otherwise
data0 = enqueue incoming(f rom, phone, data) m = hhssf, notificationi, facility, ⊥i
The following rule is applicable when a connection notification has been sent from aBCSM. If theBCSMis connected to a phone it is notified. An offhook notification is propagated backwards in the path.
event: notification(bcsm, connection, list: hd(σ)) h running, data, σ, db i broadcast (m1∪ m2)
−−−−−−−−−−−−→ h running, data, list: tl(σ), db i (5.10)
where f rom = event: sender(list: hd(σ)) phone = event: data(list: hd(σ))
prev = previous bcsm(f rom, data) m1 = notify({prev}, offhook)
m2 = notify phone(phone, data, f rom, connection)
The following rule is applicable when a busy notification has been sent from a BCSM. The BCSM is removed from the Active, P assive sets and the Incoming queue. TheBCSMis removed from the path and a busy notification is propagated backwards in the path. If any phone is connected it is also notified.
event: notification(bcsm, busy, list: hd(σ)) h running, data, σ, db i broadcast (m1∪ m2)
−−−−−−−−−−−−→ h running, data00, list: tl(σ), db i (5.11)
where f rom = event: sender(list: hd(σ)) phone = event: data(list: hd(σ))
prev = previous bcsm(f rom, data) data0 = purge(f rom, phone, data)
data00 = remove path(hprev, f romi, data0) m1 = notify({prev}, busy)
m2 = notify phone(phone, data, f rom, busy)
The following rule is applicable when a no answer notification has been sent from aBCSM. TheBCSM is removed from the Active, P assive sets and the Incoming queue. TheBCSM is removed from the path and a no answer notification is prop-agated backwards and forwards in the path. If any phone is connected it is also notified.
event: notification(bcsm, no answer, list: hd(σ)) h running, data, σ, db i broadcast (msgs)
−−−−−−−−−−→ h running, data3, list: tl(σ), db i (5.12)
where f rom = event: sender(list: hd(σ)) phone = event: data(list: hd(σ))
prev = previous bcsm(f rom, data) next = next bcsm(f rom, data) data1 = purge(f rom, phone, data)
data2 = remove path(hprev, f romi, data1) data3 = remove path(hf rom, nexti, data2)
m1 = notify({prev}, no answer) m2 = notify({next}, onhook)
m3 = notify phone(phone, data, f rom, no answer) msgs = m1 ∪ m2 ∪ m3
5.4 Rules 59
SCF communication rules
The following rule is applicable when a service request event or report request has been sent from aBCSM. The request is relayed to theSCF.
event: request(bcsm, request, list: hd(σ)) ∨ event: request(bcsm, report, list: hd(σ)) h running, data, σ, db i send (m, scf)
−−−−−−−→ h running, data, list: tl(σ), db i (5.13)
where m = hhssf, requesti
event: name(list: hd(σ))
hevent: data(list: hd(σ)), event: sender(list: hd(σ))ii
The following rule is applicable when a service report response event has been sent from the SCF. The report is relayed to the BCSMthat requested the service.
event: response(scf, report, list: hd(σ)) h running, data, σ, db i send (report, to)
−−−−−−−−−→ h running, data, list: tl(σ), db i (5.14)
where hto, reporti = event: data(list: hd(σ))
The following rule is applicable when an initiate call point of return1has been sent from theSCF. A call is initiated by initiating a new originatingBCSM, which if the call according to the message is to be active, replaces the Current Active of the phone and swaps the active to passive. If the call will not be active the requesting BCSM will be removed from the phone’s Current. Finally a initiate call point of return message is sent to the requestingBCSM.
event: request(scf, initiate call, list: hd(σ)) h running, data, σ, db i
id:=create(bcsm,state);
broadcast (m)
−−−−−−−−−−−−−−−−→ h running, data00, list: tl(σ), db i (5.15)
where hto, ph, type,
armed, nri = event: data(list: hd(σ)) ha, p, ii = current bcms(ph, data) connected = if(type = active, true, false)
state = bcsm : new(O Null, to, ph, connected, db) data0 = if(type = active
update current({h{id}, a ∪ p, ii}, ph, data), purge(to, ph, data))
data00 = add path(hto, idi, data0)
m = {hhhscf, pori, initiate call, htype, armedii, toi, hnr , idi}
1For explanation of point of return see following Chapter 6.
Chapter 6
BCP - Basic Call Process
In this chapter we will describe the Basic Call Process SIB and how this will be modeled using the Basic Call State Model. Thereafter a formal model is given of the Basic Call State Model.
6.1 DESCRIPTION
TheBCP SIB shall model the functionality of the normal call capabilities together with the ability to decide when IN functionality is needed. This model is rather coarse since the intentions are according to [IN:Q.1213, p.29–30]:
The basic call process (BCP) has been defined in 4.0/Q.1203 as a spe-cializedSIB which provides the basic call capabilities.
These capabilities enable the use ofGSL as well as other SIBs to com-pletely describe CS-1 services and service features.
It is not necessary or intended to fully model the Basic Call Process on the Global Functional Plane in CS-1, but rather to insure that the functionality of the Basic Call Process that is required on the Global Functional Plane in conjunction withSIBs be available to fully support CS-1 Service/Service features.
6.1.1 BCP
The Basic call process at the global functional plane is described only by how it interacts with the Intelligent Network service in the form of sequences of SIBs.
This is accomplished by describing the interface between the BCP and the GSL which is used to construct the SIB sequences. The interface consists of Points of initiation (POI) and Points of return (POR).
6.1.2 POI - Point Of Initiation
The Points of initiation are the points in theBCP’s execution where the Basic call process may detect that Intelligent Network functionality is required; whereupon the BCP is suspended and control is handed over to theGSL which then initiates a sequence ofSIBs. Below is a list of thePOIs.
- Call originated
This POI identifies that the user has made a service request without yet specifying a destination address.
- Address Collected
ThisPOIidentifies that the address input has been received from the user.
- Address analysed
This POI identifies that the address input has been analysed to determine characteristics of the address.
- Prepared to complete call
This POI identifies that the network as prepared to attempt completion of the call to the terminating party.
- Busy
ThisPOIidentifies that the call is destined for a user who is currently busy.
- No Answer
This POI identifies that the call has been offered to a user who has not answered.
- Call acceptance
This POI identifies that the call is active but the connection between the calling and called parties is not established.
- Active state
This POI identifies that the call is active and the condition between the calling and called parties is established.
- End of call
ThisPOIidentifies that a call party has disconnected.
6.1.3 POR - Point Of Return
The Points of return denote the different types of return that may occur from a sequence of SIBs by way of the GSL to the BCP SIB. Below follows a list of the PORs.
- Continue with existing data
This POR identifies that the BCP should continue call processing with no modification.
- Proceed with new data
This PORidentifies that the BCP should proceed with call processing with only a data modification.
6.1 Description 63
- Handle as transit
ThisPORidentifies that theBCPshould treat the call as if it had just arrived.
- Clear call
This PORidentifies that theBCP should clear the call.
- Enable call party handling
This POR identifies that the BCP should perform functions to enable call control for individual parties.
- Initiate call
This POR identifies that a new call should be initiated. This may be inde-pendent of an existing call, or may be in the context of an existing call.
Call originated
Address collected
Address analysed
Prepare to complete call
Busy
No Answer
Call acceptence
Active state
End of call BCP
Continue with existing data Proceed with new data
Clear call Enable call party handling Initiate call Handle as transit PORs POIs
Figure 6.1: Basic Call ProcessSIB
Of the above mentioned PORs thePORs Handle as transit and Enable call party handling have not been modeled. The reason for not modeling these PORs was that they were not needed in the services we have modeled so far. Further the portent of Enable call party handling PORs is not entirely clear to the author.
The rather limited view of normal call handling presented by theBCP SIBabove is not sufficient when trying to model the SIBs1. The normal call handling has to be considered at greater detail and we have used as a starting point the Basic call state model (BCSM)found in [IN:Q.1214] admirably suited for this purpose.
1A graphical depiction of theBCP SIBis shown in Figure 6.1.
6.1.4 BCSM - Basic Call State Model
The Basic Call State Model is partitioned into an originating and terminating BCSMdepending on what part of the call that is modeled.2
1. O_Null & Authorize Origination_Attempt 6. O_Exception
1 2. Collect_Info
Orig.Attempt_Authorized
2 Collected_Info 3. Analyse_Info
4. Routing & Alerting 3 Analysed_Info
7 5. O_Active
O_Answer 10
9
8
4
5
6 O_Abandon
O_Disconnect
O_Mid_Call
Route_Select_Failure
O_Call_Party_Busy
O_No_Answer
(a) OriginatingBCSM
11. T_Exception 7. T_Null & Authorize Termination_Attempt
8. Select_Facility & Present_Call
9. T_Alerting Term.Attempt_Authorized
10. T_Active T_Answer 15 12
14 13 T_Call_Party_Busy
T_No_Answer
18
17
T_Mid_Call T_Disconnect 16
T_Abandon
(b) TerminatingBCSM
Figure 6.2: Figures 4-3 and 4-4 of [IN:Q.1214], originating/terminating BCSM for CS-1
TheBCSMconsists of Points in call (PICs) which reflects normal call handling.
Detection points (DPs) are points where the need for IN functionality can be iden-tified and the basic call handling suspended while the call control is transfered to the IN functionality in question. ThePICs are represented as rectangular boxes in the figure and theDPs as smaller squares.
The DPs are related to thePOIs in that one or several DPs in the originating and terminating BCSM “implement” one POI. The POR on the other hand can
2A picture of the originating and terminatingBCSMare given in Figure 6.2.