Call Processing

Technical Manual
C&C08 Digital SPC Switching System Table of Contents
Table of Contents
Chapter 7 Call Processing........................................................................................................... 7-1

7.1 Introduction to Call Processing ......................................................................................... 7-1
7.1.1 Call Types .............................................................................................................. 7-2
7.1.2 Basic Call Process ................................................................................................. 7-2
7.2 Various Call Processes..................................................................................................... 7-4
7.2.1 Intra-office Call ....................................................................................................... 7-4
7.2.2 Outgoing Call.......................................................................................................... 7-7
7.2.3 Incoming Call.......................................................................................................... 7-8
7.2.4 Tandem Call ......................................................................................................... 7-10
7.2.5 Remote Subscriber Call ....................................................................................... 7-12
7.2.6 Number Analysis .................................................................................................. 7-12
7.2.7 Accept TNM Center Scheduling........................................................................... 7-17
7.2.8 Signaling Matching in Call Connection Process .................................................. 7-18
7.3 N-ISDN Subscriber Call .................................................................................................. 7-18
7.4 Access Network Subscriber Call..................................................................................... 7-21
7.4.1 AN Terminal Subscriber Call Initiation ................................................................. 7-22
7.4.2 AN Subscriber Basic Call-in Connection.............................................................. 7-23
7.5 Intelligent Service Call .................................................................................................... 7-24
7.5.1 SSF/CCF Processing Model ................................................................................ 7-24
7.5.2 SRF Processing Model ........................................................................................ 7-31
7.5.3 SCF Processing Model ........................................................................................ 7-33
7.5.4 SDF Processing Model ........................................................................................ 7-35
7.5.5 SMF Processing Model ........................................................................................ 7-36
7.6 Centrex Subscriber Call.................................................................................................. 7-37
7.6.1 Centrex Services .................................................................................................. 7-37
7.6.2 Centrex Database Structure................................................................................. 7-38
7.6.3 Centrex Subscriber Call Process ......................................................................... 7-38
7.7 Data Service Call ............................................................................................................ 7-41
7.7.1 Circuit-switching Access to Packet Network ........................................................ 7-42
7.7.2 Access to ISDN Virtual Circuit Service ................................................................ 7-45
7.8 Connection Control Message List................................................................................... 7-54
Huawei Technologies Proprietary
i
Technical Manual Chapter 7
C&C08 Digital SPC Switching System Call Processing
Chapter 7 Call Processing
7.1 Introduction to Call Processing

Call processing system (as shown in Figure 7-1) is an application subsystem based
on operating system and database management subsystem (DBMS). It is responsible
for connection processing of PSTN, data and ISDN services. Call processing
subsystem supports specifications according to the recommendations of ITU-T and
ETSI/CEPT. It is an integrated system supporting multiple standards.
Call processing system can be divided into three kinds of modules:
1) Call Control Block (CCB).
2) Resource Management Module (RMM), which is used for DTMF management. It
is also used for management of intra-office sending and receiving of equipment
& network.
3) Signaling Processing Module (SPM), which is used for channel associated
signaling and common channel signaling processing.
Call processing subsystem
CCB
RMMj
SPMi Public
section
Specialized
section
C&C08
DBMS
C&C08 operating system
C&C08 hardware
Figure 7-1 Call processing subsystem and its supporting environment
Communications between call processing system, OS and DBMS and between

various modules inside the calling processing system adopt pure message mode and
the data is accessed in an asynchronous manner. There is no need for the call
processing system to know the location of DB and the specific way to access DB. It
can complete the data accessing task only through the standard data query interface.
Hence, C&C08 Switching System has the following features:
7-1
1) The system is easy for expansion. Revision of call processing subsystem or data
management subsystem will not affect the subsystems other than it.
2) It supports multiple database accesses. Typical databases that C&C08 can
access simultaneously are: basic call DBMS, Centrex DBMS, IN DBMS, TMN
DBMS, etc.
Each module in call processing system uses object mechanism in Object Oriented
Method (OOM) to abstract & pack and corresponds to a finite state machine (FSM).
Each object comprises data structure and message processing interface. Data can be
classified into public data and private data. Public data is available to other objects,
which can call and use the data but cannot change them. Private data is only
accessible within the object. Message processing interface can be further classified
into input interface and output interface.
Each SPM is responsible for the handling of various standard and specifications of
one signaling system. For example, Q.931, R2 Signaling, TUP and ISUP each has its
corresponding SPM. Synchronous coordination is done between SPM and CCB
according to internal regulations of C&C08. Only an SPM needs to be added for the
addition of each new signaling system. Call processing subsystem has a good
extendibility.
7.1.1 Call Types
C&C08 switches, which can handle various types of calls including ISDN services,
can be used at various levels of position in telecom network.
7.1.2 Basic Call Process
In C&C08 call processing subsystem, all SPMs are treated equally. Synchronization
coordination is done between SPM and CCB according to the internal signaling
specification based on ITU-T Recommendation Q.931. The basic call process is
shown in Figure 7-2.
7-2
Source SPM Call control block (CCB) Destination SPM
Idle Idle Idle

Call request
1. Call source analysis

2. Authentication
3. Resource application
Setup (CLI+Source)
4. Record CLI+Source
5. Bearer capacity checking
SetupAck
6. NNI/UNI signaling matching

7. Number receiving preparation
8. Begin reporting the CLD
Information (CLD) SetupAck
9. Number analysis change

10. Call restriction
11. Number analysis
12. Service authentication
13. UNI/NNI signaling matching
number length control
Want data
Wait DB Data DBMS

Want DataACK
14. Record the called location

and relative attributes
Setup
15. Call in authentication

16. Bearer capability analysis
17. Resource application
SetupAck
Overlapping 18. Hardware equipment seizure

transfer stadge 19. UNI/NNI signaling processing
Information Req
Information Req
Information
Information
Ringing
Alerting
Send ring Alerting
Hook off
back tone
Connect
Connect
Connect ACK
Connect ACK
20. Release control

21. Charging process
Hook on Disonnect
Release
Release
Control party hooks on
Hook on Non control party hooks on

Disonnect
Disonnect
Hook on
Release
Figure 7-2 Basic call processing flow
7-3
Usually one call involves one source SPM, one destination SPM and one CCB. SPM
is responsible for protocol matching; here the protocols refer to NNI and UNI. CCB is
mainly responsible for number analysis, internal protocol control, called channel
locating and charging processing.
For the case of an easy discussion, one basic call can be viewed as being composed
of several states: call initiated, overlap sending, call proceeding, call received, active
and disconnect state. Alteration of each state reflects the transition of the call control
center. Call initiated state starts from the time when a call is received by the source
SPM and call establishment request is sent to the CCB. In overlap sending state,
control center transfers to CCB. Destination SPM is the call control center in the call
proceeding and call received states. After being established, the call enters call
proceeding state. In call disconnect state, speech channels and other resources are
released.
7.2 Various Call Processes
7.2.1 Intra-office Call
I. Call initiated state
Processing of intra-office call is illustrated in Figure 7-3.
3
DTMF
7 6 CCB
SPM-ASL
5 4
1 2
ASL DBMS
MPU
SM
1) Report off-hook 2) Query subscriber data 3) Allocate DTMF receiver

4) Apply for CCB 5) Setup message 6) SetupAck message
7) Send dial tone
Figure 7-3 Intra-office call I: call initiated
1) When ASL circuit detects an off-hook signal of a caller telephone, the terminal
processor of the subscriber line (CPU on ASL board) reports this event to MPU
via communication processor (CPU on NOD board).
2) After receiving the establishment(setup sometimes in figures) event, the SPM-
ASL on MPU queries the caller's data. If this call is allowed, it applies for and
occupies a CCB. It sets up subscriber calling state as call initiated and sends
establishment (setup) message to the network side. If the telephone set at the
7-4
caller side is a tone-frequency one, a DTMF receiver is needed to collect the

subscriber's dialing information.
3) MPU indicates to the terminal processor that the call request is responded and it
instructs the terminal processor to send specific prompt tone (dial tone or special
dial tone) to the caller.
II. Overlap sending state
1) When the receiver gets first digit of the number, it stops the signal tone and the
call enters overlap sending state.
2) After receiving certain number of digits, MPU begins processing the information
received. CCB calls database module (DBMS) function to analyze number prefix.
From the analysis, it concludes that the call belongs to intra-office and
determines the number length.
3) After receiving enough number of digits, SPM-ASL releases the DTMF receiver.
The call turns into outgoing call proceeding state.
III. Outgoing call proceeding state
1) CCB queries database for the called subscriber and after finding it, sends
occupancy indication message to the called subscriber side.
2) At the called subscriber side, the equipment state of the called subscriber is
queried. If it is idle, the SPM at the called subscriber side rings to the called
subscriber and sets the called party state as incoming receiving and reports to
CCB that the called is ringing.
3) After CCB confirms the ringing, it sends ring back tone to the caller. Now the call
turns to call receiving state.
IV. Call-receiving state
Processing of intra-office call in receiving state is as illustrated in Figure 7-4.
7-5
7 4
8
3 1 6
DTMF SPM-ASL CCB SPM-ASL
10
11 5
9
2
ASL1 DBMS ASL2
Caller 12 The called
1) First digit 2) Stop dial tone 3) Followed digits

4) Information message 5) Prefix analysis 6) Call processing message
7) Release DTMF 8) Setup message 9) Called party ringing
10) Alerting message 11) Alerting message 12) Hear ring back tone
Figure 7-4 Intra-office call II: call receiving
1) ASL circuit detects the answer of the called when the called hooks off and cuts
off the ringing current. It sends connect message to the network side.
2) CCB stops sending ring back tone to the caller and connects the speech path for
the caller and the called. Now, the call enters active state.
V. Call disconnect state
Processing of intra-office call in call disconnect state is illustrated in Figure 7-5.
5 9 3
ASL1 SPM-ASL CCB
7 8 6
Caller
1 2 10
11 12
ASL2 SPM-ASL
4
13
The called
1) Report called off-hook 2) Connect message 3) Connect message

4) ConnectAck message 5) Conversation 6) ConnectAck message
7) Report on-hook 8) Disconnect message 9) Release message
10) Release message 11) Send busy tone 12) Release complete message
13) Report on-hook
Figure 7-5 Intra-office call III: conversation and call disconnection
7-6
1) When ASL circuit detects the on-hook signal from the caller, it sends release
request to CCB.
2) If CCB decides that the call can be cleared after querying the control mode (in
the no party controlling release mode), it sends call release message to the
SPMs of both the caller and the called.
3) When the caller's SPM receives the call release message, it turns the caller state
to idle.
4) When the called side SPM receives the release command, it sends busy tone to
the called and starts busy-tone timer.
5) When the called party hooks on, its state turns to idle.
7.2.2 Outgoing Call
Outgoing call connection is similar to that of intra-office call in the process from caller
off-hook to prefix analysis, where the CCB determines that the connection is an
outgoing call. The following states are as follows:
I. Overlap sending and receiving state
Processing in overlap sending and receiving state for outgoing calls is illustrated in
Figure 7-6.
9
6
11 10
DTMF SPM-ASL CCB
12
1
ASL
DBMS
7
3 2
MFC SPM-DT
8
5 MPU
4
DTM SM
1) Select an idle outgoing

2) Setup message 3) Seize register
trunk
4) Send seizure signal 5) Report seizure acknowledge signal 6) SetupAck message
7) Send forward register
8) Called party idle signal 9) Alerting message
signal
12) Connect subscriber circuit
10) Alerting message 11) Release DTMF
and trunk circuit
Figure 7-6 Outgoing call: overlap sending and receiving state
7-7
1) CCB queries office data, selects an idle trunk and sends call establishment
request to SPM-DT.
2) SPM-DT makes preparation for the trunk to call out. If the signaling of the trunk
circuit is of CAS kind, a spared MFC will be allocated. Then it sends seizure
signal to the remote exchange. After receiving the seizure acknowledge signal, it
sends call establishment response message to CCB.
3) SPM-DT receives information sent by CCB, according to which, it indicates the
MFC register or the message transmission module to send the called number,
and then responds to the backward information sent by the remote exchange.
4) After remote exchange has collected all the information needed for connection, it
checks the state of the called party. If the called party is found to be idle, it rings
the subscriber and sends backward information to the caller exchange, indicating
that the called state is idle.
5) SPM-DT of the caller exchange reports to CCB that the called is alerted and then
releases the MFC register. CCB informs the caller that the called subscriber is
idle and connects through the speech channel. When caller hears the ring back
tone from the remote exchange, the call turns to call receiving state.
II. Call receiving state
1) The called party hooks off and the remote exchange sends back answer signal.
2) SPM-DT sends connect request to CCB and CCB upon receiving it, turns the call
into active state. The caller and the called party start conversation.
III. Call disconnect state
1) After receiving the on-hook signal by the caller, the ASL circuit sends the
disconnect request to CCB.
2) If CCB confirms that the call can be cleared after querying its control mode. It
sends out call release command to the SPMs of both the caller and the called.
3) When caller's SPM receives the disconnect command, it changes the caller state
to idle.
4) Trunk module sends forward release signal to the remote exchange and starts
the timer. After receiving the release guard signal from the remote exchange or
when the timer runs out, the trunk module turns the trunk into locked state.
7.2.3 Incoming Call
I. Call initiated state
Processing of incoming call in initiated state is as shown in Figure 7-7.
7-8
5
MFC
2 4
Trunk control CCB
table
1 3
DTM
MPU
SM
1) Report seizure signal 2) Seizure acknowledge signal 3)Setup message

4) SetupAck message 5) Allocate MFC register
Figure 7-7 Incoming call: call initiated state
1) DTM detects the seizure signal sent from the opposite exchange and reports it to
MPU.
2) MPU applies for CCB. If channel associated signaling is involved, MFC circuits
should also be applied. The connect state is set as call initiated.
3) MPU indicates DTF card to send seizure acknowledge signal back to the
opposite exchange and make preparation for number receiving.
II. Overlap sending state
1) When the register receives the first digit from the opposite exchange, the call
turns into overlap sending state.
2) When the received digits reach the preset number, CCB initiates prefix analysis.
If the called subscriber is confirmed to be a subscriber of this office, the call is
classified as in-coming call and then CCB determines the total number of digits
of the call to be received.
3) After receiving the called number, if caller's category is required, another request
signal will be sent to the opposite exchange by trunk module.
4) After called number and caller category are collected, CCB inquires database to
find out the called subscriber and sends out seizure message.
5) Similar to intra-office call, the subscriber side sends out command to ring the
called if it is idle and reports the state of the called to CCB. CCB sends message
to SPM-DT indicating that the telephone set at the called side is ringing. After
register signal has been sent, register is released. Ring back tone is sent to the
opposite exchange. The call turns into call receiving state.
III. Call receiving state
1) When called party answers, CCB receives the call connect request from the
called and sends out connect message to SPM-DT. The SPM-DT will stop
sending ring back tone and connect the speech channel.
7-9
2) SPM-DT sends answer signal to the opposite exchange and the call turns into
conversation stage.
IV. Call disconnect state
1) When opposite exchange sends forward release signal, SPM-DT reports the
disconnect request to CCB.
2) If CCB confirms that the call can be released, it sends out release message to
the SPMs of both the caller and the called.
3) When SPM-DT receives the release command, it sets trunk state to idle.
4) When SPM of the called party receives release command, it sends out busy tone
to the called and starts busy-tone timer.
5) As the called hooks on, the state turns to idle.
7.2.4 Tandem Call
Tandem call processing is the same as that of incoming call in stages from trunk
seizure to prefix analysis. After prefix analysis, if CCB finds that it is a tandem call,
then call processing proceeds to the stages as given below:
I. Overlap sending/receiving state
Figure 7-8 is the processing illustration of overlap sending/receiving state of tandem

call.
7-10
12
10
CCB
M FC S P M -D T I 9
11
2
6
13 1
In c o m in g
DBMS
tru n k
8
7
MFC S P M -D T O
3
5
O u t g o in g
tru n k
4
1) Find outgoing trunk circuit 2) Setup message 3) Seize register

6) SetupAck
4) Send seize signal 5) Report seize acknowledge signal
message
7) Send forward register signal 8) Called party idle signal 9) Alerting message
11) Send called idle signal and 12) Register signal
10) Alerting message
release register release complete
13) Connect through the outgoing trunk
circuit and incoming trunk circuit
Figure 7-8 Tandem call: overlap sending and receiving
1) CCB inquires exchange data and selects an idle trunk from trunk control
modules. It then sends the call establishment request to the idle trunk.
2) SPM-DTO makes preparation for the trunk for calling. If CAS trunk is involved, a
spared MFC will be allocated. It sends seizure signal to remote exchange,
receives seizure acknowledge signal and then sends call establishment
response to CCB.
3) CCB receives the message sent by trunk and transfers it to SPM-DTO. SPM-
DTO, according to the information, instructs MFC or message transfer module to
send the called number and responds to the backward information sent over by
remote exchange.
4) When remote exchange collects all the information needed for call connection, it
checks the state of the called party. If the called subscriber is idle, it sends
backward signal to indicate the idle state of the called.
5) SPM-DTO reports alerting to CCB and releases register circuit. CCB indicates to
SPM- DTI that the called party is idle. SPM-DTI sends back the idle signal to the
originating exchange and delays releasing register.
6) CCB connects through the outgoing and incoming trunk to form the speech path
and then the call turns into receiving state.
7-11
II. Call receiving state
1) The called hooks off and the initiating exchange sends answer signal. Then
SPM-DTO reports the connect request to CCB.
2) CCB sends connect message to SPM-DTI. SPM-DTI sends answer signal to
originating exchange. The call turns into active state.
III. Call disconnect state
1) Upon receiving the forward disconnect signal sent from the initiating exchange,
SPM-DTI sends disconnect request to CCB.
2) When CCB confirms that the call can be released, it sends release indication to
the caller and the called.
3) When SPM-DTI receives the disconnect indication, it puts the trunk into idle state.
4) SPM-DTO sends forward release signal to remote exchange. When release
guard signal from remote exchange is received, SPM-DTO turns the trunk into
idle state.
7.2.5 Remote Subscriber Call
C&C08 supports various remote subscriber access modes, such as RSM, RSA and
RIM. The difference between the remote subscriber and local subscriber lies in the
physical layer and data link layer. As far as the third layer is concerned, call
processing is the same as that of the local subscribers.
7.2.6 Number Analysis
Caller category
(CAT)
Number New number
prepare
Priority selection
Number code
analysis Priority Call priority
Number analysis definition table
source code
Service Release code
Release control Release control mode
analysis table mode table
Service attribute
Call Address attribute ind.
Call source source CAT
Time Route Additional signaling info.
code table Number special
selection New number reanalysis
Route selection processing table
code
source code
Route analysis Route number
Failure process source code

Charging source code
Figure 7-9 Number analysis process
Number analysis can be divided into four steps:

1) Call source analysis
7-12
2) Number preparation
3) Service analysis
4) Route analysis
As illustrated in Figure 7-9, Number analysis is an iterative process. If the input
number is not matching the number set in database to the maximum degree, analysis
will be done again when next digit is received. The output of number analysis is:
z Call priority level
z Release control mode
z Service type
z Service attribute
z Minimum number length, maximum number length
z Analyze pre-received number length
z Additional signaling information
z Route number
z Failure processing source code
z Charging source code
I. Call source analysis
Subscribers or trunk circuit groups are classed into groups; the code to represent a
group is call source code. In call source table, the features of various groups are
described as follows:
z Analyze pre-received number length: Control the pre-received number and
analyze its number length.
z Number preparation flag: It determines whether the number has to be changed.
z Number analysis source code: It serves as the key field in the call source table
together with CLD.
z Route selection source code: It is used as the key field in the route analysis
course.
z Failure processing source code: When call fails, it is the key field used for
inquiring failure processing table along with failure cause.
z Charging source code: It is an attribute of the call source to which charging
analysis will be referred.
II. Number preparation
In this step, deleting, inserting or replacing one or several digits can change the caller
number and the called number. The number of the network where the called
subscriber resides can also be changed to achieve the intercommunications between
various networks.
III. Service analysis
Service analysis uses number analysis source code, network number and destination
number as the key fields to get the following service features:
7-13
z Service type: Basic service, test service, supplementary service, intelligent

service, special access code or Centrex service.
z Service feature: Intra office, local area, local toll, national call, international call,
supplementary service, intelligent service and Centrex group incoming/outgoing
service.
z Maximum number length, minimum number length: Used to indicate the number
length limit.
z Priority selection code: It determines call priority.
z Release control mode code: It determines release control mode.
z Route selection code: Used to determine route number for outgoing calls.
z Prefix special process code: It specifies whether the prefix special processing
has to be done.
z Additional signaling information: Indicates some additional signaling
requirements of the call.
IV. Route analysis
The C&C08 Switching System has the traffic routing facilities in conformity with ITU-T
Recommendation E.170 and E.172 White Book. Routing of international traffic in the
PSTN and ISDN is conducted according to ITU-T Recommendation E.171.
The C&C08 Switching System allows up-to 1000 inter-exchange trunk routes. The
minimum number of routes may be as low as one while the maximum number of
outgoing routes may exceed 1000, but it is limited by the maximum size of the whole
exchange.
The routes can be selected according to the pre-determined sequence, which, if
necessary, can be altered by MML command.
Route analysis takes accounts for five factors: route selection source code, calling
subscriber category (CAT), current time, route selection code and address property
indication. In C&C08 Switching System, route is selected dynamically, i.e. different
call sources can select different routes to call the same destination code and call
made by the same source to a destination may have different route choice at different
calling time.
C&C08 route data is constructed in tree-structure. See Figure 7-10.
7-14
Route
......
Sub-route 1 Sub-route m
...... ......
Trunk group 1 Trunk group n
Circuit 1 Circuit j Circuit 1 ... Circuit k

...
Figure 7-10 Route data tree structure
C&C08 realize automatic and real time check of traffic by setting overload threshold
and monitoring the traffic of every route, sub-route and trunks in real time.
C&C08 performs self-adapting routing algorithm according to the real time traffic
detected to balance the traffic distribution, thus achieving balanced flow control and
enhanced communication quality.
1) Normal routing strategy
When switch load is less than the designed load standard, traffic is reasonably
distributed to prevent traffic congestion.
z Dynamic routing strategy
According to this strategy, route and sub-route selection sequence may be different at
different time, so that the traffic of various routes and sub-routes can be balanced.
Figure 7-11 illustrates this routing strategy taking the dynamic nonhierarchical routing
(DNHR) method as the example.
7-15
Beijing
④ ③ ①
②
Urumqi ⑤ Nanjing
⑥ ⑩
Wuhan ⑧
⑨
⑦
Shanghai
Sequence Routing sequence between

Beijing and Shanghai
1 {→~→{→} 06:00–10:00
2 |→{→}→~ 10:00–14:00
3 |→}→~→{ 14:00–18:00
4 |→~→}→{ 18:00–22:00
5 |→{→}→~ 22:00–06:00
Figure 7-11 DNHR scheme illustration
z Group selection sequence mechanism

The trunk group can be selected after the determination of sub-route. It is possible to
select the trunk group by call priority, or if the priority is the same, selection can be
made according to the utility proportion of trunk groups.
z Module array searching mechanism
C&C08 is a distributed system comprising multiple modules. Group selection can be
done in the predetermined module sequence to balance the traffic load in each SM.
2) Extended control strategy
When overload occurs in the network but not serious at the time, some network
resources can be allocated to dredge the traffic, in other words, traffic on the
congested route can be transferred to other route with low load.
z Use temporary alternate route
The load on congested sub-routes is transferred to other sub-routes.
z Restrict direct route
Traffic is restricted from entering direct routes, which are of the highest priority in
route selection and some are distributed to alternate routes when traffic on direct
route tends to be congested.
z Skipping
Some selecting sequence may have a certain circuit group skipped and select its next
one directly.
3) Protective control
During network congestion, clear the calls with less connection possibility. This
strategy is used when extended control methods are not effective.
7-16
z Cancel alternate route

In an already congested network, control alternate routing to reduce multi-link
connection.
z Number blocking
Block some specific destination codes to reduce traffic in the congested office
directions.
z Interval call control
Describe maximum number of call attempts to a certain destination and via a certain
route in a specific period.
z Fixing call direction of circuits
Change some two-way trunk circuits into circuits allowing only incoming calls. In this
way, traffic output from this exchange can be controlled so that the followed network
routes can be protected.
z Circuit rejection
For outgoing/two-way trunks, these circuits are to be in the seizure refuse state; while
for incoming/two-way trunks, any incoming call to seize the trunk is to be refused by
sending the blocking signal from BAM. Thus, usage of some circuits will be paused.
4) Emergency control strategy
This strategy is taken when serious switching congestion or network congestion
occurs.
z Outgoing call restriction
Specific subscriber outgoing calls are restricted when CPU occupancy rate exceeds
the preset threshold.
z Use reserved circuits
Reserved circuits may be used to serve some special traffic when network is
congested, such as network management traffic.
5) Automatic congestion control (ACC)
ACC messages may be sent in case, a specified load level is exceeded in the system,
which will then stop sending non-terminating traffic. The processing is according to
ITU-T Recommendation Q.764.
7.2.7 Accept TNM Center Scheduling
C&C08 can accept telecommunication network management center (TNM center)

scheduling. See Figure 7-12:
SM1
NM data
NM command
TNM center BAM FAM
NM data
SMn
Figure 7-12 C&C08 accepts TNM scheduling
7-17
TNM transmits NM instructions to BAM via a data path. BAM accepts and explains
these instructions. It then queries related data, generates NM data tables that can be
used by FAM and SM. It sends the tables to every SM via FAM for execution.
7.2.8 Signaling Matching in Call Connection Process
In C&C08, the various signaling systems are converted through encapsulation to

ISDN signaling for uniform processing in call connection. But encapsulation cannot
solve the channel associated signaling problem completely. Since ISUP is a Common
Channel Signaling, the matching between Channel Associated Signaling and
Common Channel Signaling must be considered in C&C08 signaling processing.
According to Q.601-Q.699 in ITU-T blue book, C&C08 software system forms C&C08
internal signaling protocol by abstracting the signals of various kinds of signaling
systems. The conversion between standard protocols and C&C08 internal protocol is
carried out by SPM and the CCB completes synchronized coordination between
SPMs.
When there is a situation where two signaling systems coexist, call processing must
synthesize them to determine the time for connecting through the speech channel.
7.3 N-ISDN Subscriber Call

N-ISDN subscriber can access the C&C08 exchange via BRI on DSL board. It is
different from analog subscriber mainly in layer 1 and layer 2. The following functions
in layer 3 are enhanced:
z B-channel selection
z Compatibility check
z Interworking processing
The connection process of incoming and outgoing calls of N-ISDN subscriber is
described in the following sections.
I. Call initialization stage
See Figure 7-13.
7-18
5
SPM-DSS CCB
3 4
U interface
DSL
1
2
TE1 DBMS
MPU
USM
1) Send setup 2) Inquire subscriber data, check 3) Apply for CCB

message through UNI bearer capacity acknowledge signal
5) SetupACK /or Call proceeding / or
4) Setup message
progress /or alerting message
Figure 7-13 Digital subscriber call: call initialization
Choose B-channel and establishment is acknowledged:

1) Subscriber sends an establishment message via UNI. This is reported to MPU
via DSL card and communication processor.
2) When DSS1 signal processing module (SPM-DSS1) in MPU receives the setup
event, it checks occupancy state of the corresponding B-channel and inquires
caller data. If this call is accepted and CCB resource is allocated, then the SPM-
DSS1 transits to call initiation state and sends establishment message to
network side.
3) MPU indicates the B channel to DSL. It also indicates that this call request is
responded.
II. Overlap sending stage
During this stage, there are three possibilities of establishment message that the
caller sends to CCB:
1) Called number information is not included.
2) Incomplete called number information is included.
3) Called number information included is regarded to be incomplete by network.
When MPU receives setup message, network side starts the timer and sends
SetupACK to subscribers, entering overlap sending state.
After receiving SetupACK, subscriber enters overlap sending state and sends the rest
of the call information in one or more information messages.
When certain number of digits is received, MPU begins processing the information
received. CCB analyzes the number and gets the service feature, call type and
number length of the call. When receiving the number complete indication carried in
the information message or when the number analysis is complete, MPU sends call
proceeding message to subscriber.
7-19
III. Call proceeding state
1) CCB inquires database to find out the called subscriber and sends setup
message to the UNI interface at the subscriber side.
2) When the subscriber receives the setup message, it first checks compatibility
and then selects an idle B-channel according to the message channel indication
in the setup message.
3) Call proceeding, alerting or connect messages can be used correspondingly to
enter call-in processing, call receiving or connect request state respectively. For
overlap sending, SetupACK message is used to respond to enter overlap
receiving stage.
IV. Overlap receiving stage
1) When the setup message received by the called subscriber does not include the
complete called number information, it enters overlap receiving state by sending
SetupACK message. During this state, CCB receives the subsequent information
from the network side.
2) When the called subscriber confirms that enough call establishment information
is received, CCB sends call proceeding, alerting or connect message accordingly
to enter call-in processing, call receiving or connect request state.
3) Origination of interface interworking notice.
V. Call verifying state
1) When called subscriber has collected enough information and the call is
accepted, call proceeding or alerting message is sent back.
2) Terminal interfaces interworking notice: This is included in the call control
messages when state changes are required (SetupACK, Call Proceeding,
Alerting or Connect); when the relevant state change is not needed, it is included
in Progress message.
7-20
VI. Call receiving state
5 11
SPM-DSS1 CCB SPM-DSS1
6 3,4 10
8
DSL 2 9
12
1, 7 DSL
DBMS
MPU
USM
2) Inquire caller data, check

1) UNI sends Setup message 3) Apply for CCB
bearer capacity
5) SetupACK/Call 6) SetupACK and B-channel
4) Setup message
Proceeding/Alerting message selection
7) Subsequent messages with 8) Subsequent messages with
9) Number analysis
information information
12) SetupACK/ Call
10) Setup message and B- 11) Setup message, and
proceeding/Alerting and
channel selection compatibility check
interworking notice
Figure 7-14 Call receiving stage
As shown in Figure 7-14, when the called answers, connect message is reported to
the called SPM-DSSI in MPU by DSL. The same message is transmitted to the caller
via CCB and caller side SPM-DSS1. Then the ring back tone is stopped and the call
enters conversation state.
7.4 Access Network Subscriber Call

The C&C08 Switching System provides standard V5.1 and V5.2 interfaces
conforming to ITU-T Recommendations G.964~965.
V5.2 interface offers a standard protocol for Local Exchange (LE) to connect to any
access network (AN) equipped with V5.2 interface, through which AN subscriber can
be offered with services, such as switching, leased line and semi-permanent
connection. V5 interface has three layers: 1) physical layer, which is the 2 Mbit/s
protocol interface specified in G.703, G.704 and G.706; data link layer, including V5EF
sub-layer and V5DL sub-layer; 2) network layer, includes five protocols: PSTN
Signaling Protocol, Control Protocol, Link Control Protocol, Bearer Channel
Connection (BCC) Protocol and Protection Protocol. In C&C08, DTM implements the
physical layer function. The second layer function is achieved by LAP-V5.2 board; 3)
the third layer protocols are transferred by LAP-V5.2 board and processed by MPU
board (see Figure 7-15).
7-21
2Mb/s Semi-permanent connection
User port AN
LAP V5.2
User port
AN
Switch network
V5.2 MPU
SM
AN Access network LE Local exchange
Figure 7-15 V5 interface illustration
Signaling of all the layer 3 protocols is transmitted via 2 Mbit/s communication

channel. V5 interface supports 1~16 2 Mbit/s links working in active/standby mode or
load-sharing mode. A link can be allocated with a maximum of three communication
channels to satisfy the request of D-channel messages being transmitted via different
channels when ISDN subscriber calls. Communication channel distribution sequence
for each 2M link is: TS16, TS15, and TS31.
7.4.1 AN Terminal Subscriber Call Initiation
The flow chart of AN subscriber calling-out is shown in Figure 7-16.
7-22
Subscriber AN LAP V5.2 SPM CCB
Off hook ESTABLISH seizure Off hook Setup
ESTABLISH ACK Setup ACK

Alloc_TS Setup ACK
ALLOCATION (BCC protocol)
ALLOCATION COMP Alloc_TS_comp

Apply for DTMF, send dial tone
Number sending
The same as ordinary call process
Conversation stage
SIGNAL (on-hook)
If caller Onhook
Disconnect
hooks on first
Disconnect Release
DISCONNECT
DEALLOCATION Free_TS
DISCONNECT COMP Disconnect comp
DEALLOCATION COMP Free_TS comp

Release complete
Idle
If called Release
hooks on first Free_TS
DEALLOCATION
DEALLOCATION COMP
Free_TS Comp Release complete
SIGNAL (on-hook) Onhook
DISCONNECT Disconnect
DISCONNECT COMP Disconnect comp
Idle
Figure 7-16 AN subscriber call-out process
7.4.2 AN Subscriber Basic Call-in Connection
The flow chart of AN subscriber called-out is shown in Figure 7-17.

Subscriber AN LAP_V5.2 SPM CCB
Allosc_TS Setup
Allocation
Allocation comp Allosc_TS_comp
Setup
Establish
Ring Discriminated ring

Establish ACK Setup ACk Alterting
Followed is the same as

ordinary call procedure
Figure 7-17 AN subscriber call-in process
7-23
Establishment message includes AN subscriber port number information. According to

the port number, AN subscriber number and other subscriber data can be found.
7.5 Intelligent Service Call
7.5.1 SSF/CCF Processing Model
SSF/CCF model consists of Basic Call Manager (BCM), IN-Switching Manager (IN-
SM) and Feature Interactions Manager/Call Manager (FIM/CM). Also, it describes the
relations between BCM & IN-SM, relations among BCM, IN-SM & FIM/CM and all the
functions offered by SSF/CCF. Figure 7-18 is an SSF/CCF model of single end (caller
or called) Service Logical Processing Instance (SLPI).
SCF SLPI A
<information flow>
SSF
SCF access management
IN local resource Function group/entity

data management INswitching management
INswitch state model instance Administration data

<IN-SSM> Function group not
INlocal resource data <IN-SSM events> required in INCS-1
<Resource Control>
<XXX> The title to be marked

Non-INfeatures
management Feature compatibility/call management
Can interact with
CCF specific customer
Basic call management
Basic call resource
data management <BCSM>
SRF <Basic call triggers>
<Basic call events>
CCAF Basic call resource data

Bearer control CCAF
T1143840-92
Figure 7-18 SSF/CCF model of single end SLPI
1) BCM
BCM offers basic call/connection control to establish user's communication path.
Meanwhile, it also detects basic call/connection control event, invokes IN service logic
request or reports to the active IN service logic in operation.
A call state transition chart, or a basic call state model (BCSM) can be used to
illustrate the basic call/connection control process. In INCS-1, the origination part of
IN call is separated from the termination part, hence, correspondingly BCSM includes
two parts: origination BCSM and termination BCSM. Origination BCSM describes the
state transition of basic call/connection at call origination end, while the termination
BCSM describes that at call termination side. See Figure 7-19 and Figure 7-20:
7-24
O_Abandon
1. O_Null and attempt
O_No answer
anthentication
10 O_attempt authentication passed

1
2. Collect information
Information collected
2
3. Analyze information
Information analyzed
3
4
4. Select route and alert
Router_selection_failure
5
O_called_party_busy
O_answer 6
7 O_no answer
9 5. O_Activate
O_disconnect
8
O_in conversation O: originating end
Figure 7-19 BCSM at the originating end
T_abandon
11. T_exception 7. T_Null and attempt authentication
T_Attempt authentication passed

18
12
13 8. Select_facility and
existing call
T_called party busy
14 9. T_alert
T_no answer
15 T_answer
10. T_activate 17
T_disconnect
16
T: Terminating end T_in conversation
Figure 7-20 BCSM at the terminating end
In BCSM, each component composes four elements: Point In Call (PIC), Detection
Point (DP), Transition Process and Event. Refer to Figure 7-21.
7-25
Transition
Event
DP
PIC
Figure 7-21 BCSM elements
PIC identifies CCF activities associated with IN service logic requests; DF represents
the point at which control transition occurs in basic call/connection process; Transition
process describes the direction for which the basic call/connection process heads;
Events are the triggers which cause the transition from one PIC to another PIC.
2) IN-SM architecture
SRF FEAM SCF
SSME-control
SSF ... ... SSME

FSM SSME FSM
SSF
FSM FSM
SRF: Specialized Resource Function
SCF: Service Control Function
FEAM: Function Entity Access Management
SSME-Control: SSF Management Entity
SSF FSM: SSF Finite State Machine
SSME FSM: SSF Management Entity Finite State Machine
Figure 7-22 IN-SM architecture
As illustrated in Figure 7-22, SSF Management Entity (SSME) executes all

management functions relevant to SSF operation. This comprises an SSME-Control
and several SSME FSM instances. Functional Entity Access Management (FEAM)
implements interface function between SSM and the other functional entities. FEAM
formats and queues all the messages to be sent or received by SSF from
corresponding functional entities, such as SCF and SRF (if necessary).
Besides, SSME-Control is responsible for generating SSME FSM instance upon
receiving any activation event that is asynchronous to the call process. Of course,
event synchronous with the call results in the generation of SSF FSM instance.
* SSME state transition
SSME FSM can complete operations related to SSF management and supervision
functions, such as 'Activate Service Filtering' and 'Call Gap'.
After receiving these operations, SSF assigns SSME FSM to take charge of the
related processing. State transition in the process is illustrated in Figure 7-23.
7-26
em3
State mb
Process irrelevant to call
em1 em2
State ma
idle management
Figure 7-23 SSME FSM state transition illustration
Initially, SSME FSM is in 'idle management' state. Once it receives operations

irrelevant to the call, it changes to 'processing irrelevant to call' state.
Operations irrelevant to call include:
z Request current status report
z Request status change report
z Request first state match report
z Activate service filtering
z Call gap
It should be noted here that 'Call gap' operation can be received either during the call
or outside the call, but 'Activate service filtering' can only be received outside the call.
Service filtering process describes the SSF and SCF service management process,
as shown in Figure 7-24 and Figure 7-25.
S ta te m a
A ctiva te se rvice filte rin g
P a ra m e te r F a lse
va lid ify ch e ck
T ru e
S e rvice filte rin g
p a ra m e te r co n figu ra tio n R e tu rn e rro r
S e t a ctiva tio n fla g

S ta te m a
S ta te m b
Figure 7-24 SSME FSM state transition flow (state ma → mb)
7-27
State mb
Activate Interval timeout Filter timeout

Call service filtering
No Yes
Valid Filter timeout Service filtering Service filtering
activation flag response
response
Yes No
Service filtering
No response
Call Within filter range State ma
report
Yes Reset interval
Call timer
Call filtering State ma
report
State mb
State mb
State mb State mb
Reset service
filter attributes
State ma
Figure 7-25 SSME FSM state transition flow chart (state mb → ma)
* SSF state transition

The state transition of SSF during the processing of IN calls/call attempts by SSP is
illustrated in Figure 7-26:
e1
State a e12
idle
e9 e4 e3
e11
State c State f
wait for instructions e10 monitoring
e6 e5 e7
e14
State d: wait for end of e8 State e: wait for end of
interaction temporary connection
e13 e15
Figure 7-26 SSF FSM state transition illustration
It can be seen from the above chart that SSF states include:
State a: idle
State c: waiting for instructions
State d: waiting for the completion of user interaction
State e: waiting for the completion of temporary connection
7-28
State f: monitoring
SSF FSM state transition is discussed below.
For example, an IN call is initiated by a subscriber, which causes IN-SM to move from
the 'idle' state to the state of 'waiting for instructions', as illustrated in Figure 7-27.
State a
Idle
IN call
Initial DP
Set timer
State c
Wait instruction
Figure 7-27 SSF FSM state transition flow chart (state a → c)
While IN-SM is waiting for instructions, it receives an instruction for operation issued
from SCF. It performs related processing to control IN service processing logic If SCF
needs to get more information from the subscriber, such as ACC service card number,
the network must interact with the subscriber. Therefore, SCF sends 'Connect to
Resource' operation to SSF. The process is as shown in the following flow chart of
Figure 7-28.
Stated : wait for the completion

of the interaction with the user
Disconnect forward connection
Clear bearer connection

with the specialized resources
Set timer
State c
wait for instruction
Figure 7-28 SSF FSM state transition flow chart (state c → d)
After IN-SM receives this operation, it instructs CCF to establish bearer connection
between IN subscriber and specialized resources. It enters the state d 'waiting for the
completion of the interaction with subscriber'. In this state, the network interacts with
the subscriber to get more information to complete this IN service processing. The
information inputted is received by Specialized Resource Functional entity (i.e. SRF)
and reported to SCF. If SCF has got enough information from the subscriber, it sends
'Disconnect Forward Connection' operation to SSF. Receiving this operation, IN-SM
7-29
instructs CCF to disconnect bearer connection between IN subscriber and specialized

resources. Then it enters state c 'waiting for instruction' and waits for SCF instruction
again. The process is as shown in the following flow chart of Figure 7-29.
Stated : wait for the completion

of the interaction with the user
Disconnect forward connection
Clear bearer connection

with the specialized resources
Set timer
State c
Figure 7-29 SSF FSM state transition flow chart (state d → c)
In order to collect relevant call information after IN call completion, generally SCF
requests SSF to collect related information by sending a 'Call Information Request'
operation. Meanwhile, to establish connection between IN subscriber and destination,
SCF sends another 'Connect' operation to continue this IN call connection. The
process is as shown in the following flow chart of Figure 7-30.
State c
Call information request
Call information
collection and process
Connect
Continued call connection

process
State f
monitoring
Figure 7-30 SSF FSM state transition flow chart (state c → f)
At this time, IN-SM enters 'monitoring' state f, in which it monitors the on-hook event
of the ‘caller’ and the ‘called’. Once a party hooks on, IN-SM sends 'Call Information
Report' to SCF to report all related call information collected. Afterwards, if there are
no other requests pending, this call is cleared to release the related resources and it
returns to 'idle' state. The process is as shown in the following flow chart of Figure 7-
31.
7-30
State f
monitoring
One party hooks on
Call information report
Clear call,
release resources
State a
idle
Figure 7-31 SSF FSM state transition flow chart (state f → a)
There is a state not mentioned in the above diagram, viz., state 'waiting for the
completion of temporary connection'. This state is to enable SSF to establish bearer
connection with specialized resource equipment, i.e. IP. In this case, instead of
entering state d 'waiting for the completion of interaction with user (viz., subscriber)',
IN-SM enters 'waiting for the completion of temporary connection' state. The working
principle is the same as indicated above and not explained here again.
7.5.2 SRF Processing Model
In order to realize the processing of specialized resources and interactive control

between SCF and SSF, SRF takes the structure as shown in Figure 7-32.
SCF FEAM SSF
SRME
SRSM SRSM …… SRSM
FEAM: Functional Entity Access Management

SRME: SRF Management Entity
SRSM: SRF State Machine
Figure 7-32 SRF FSM structure
FEAM performs access management between SRF and other functional entities like
SCF and SSF, for setting up and maintaining interface with SCF and SSF; transferring
7-31
the massage from SSF and SCF to SRME; formatting, queuing and sending the
massage received from SRME to SSF or SCF. The SRF Management Entity, SRME,
is in charge of such functions as SRSM object creation, activation and maintenance.
It explains and translates information transmitted between SRSM and other functional
entities.
SRSM executes specialized resource processing. When SSF initiates an IN call, if
specialized resource is needed, it generates an SRF FSM, namely, an SRSM
instance.
State transition during the process of an IN call by SRSM is illustrated in Figure 7-33.
(E1) Connect_Request_ from SSF
1. Idle
(E4) SRF_sanity_Time out (E10) Connection_Released
(E3) Connection_Released_from_SSF from_SSF
2. Connected Assist_Request_Interaction
Disconnect_Bearer_
Connection
(E5) Assist_Request_Instructions_Needed
(E11) Disconnect_to_SSF
(SRF Initiated disconnect case)
(E12) SRF_Sanity_Time out
3. User interaction
(E2) PlayAnnouncement/PromptAndCollectUser
Information_from_SCF
(E5) PlayAnnouncement/PromptAndCollectUserInformation_from_SCF
(E6) Cancel_from_SCF
(E7) SRF_Report_to_SCF
(E8) PlayAnnouncement/PromptAndCollectUserInformation_Cancelled_to_SCF
(E9) Cancel_Error_to_SCF
Figure 7-33 Illustration for SRSM state transition
In order to offer a full illustration of SRF basic processing, the SRSM state transition
process is described below. It is in a similar way with that used by SSF.
At the beginning, SRSM is in 'idle' state. Upon receiving a bearer signaling
connection from SSF, it moves to a 'being connected' state in which SRF has
established bearer path connection with the subscriber. But SRF has not received
'Play Announcement' and 'Prompt and Collect User Information' operations from the
SCF. On receipt of one of these two operations, SRSM transfers from this state to
'user interaction' state. Now SRSM begins real interaction with the subscribers like
number receiving by DTMF, etc. Once SRF completes the operations sent by SCF,
connection release can automatically be started, or it may also be disconnected by
SSF under the control of SCF. After this, SRSM returns to 'idle' state.
7-32
7.5.3 SCF Processing Model
SRF FEAM SSF
SCME-control
... ... SCME

SCSM
FSM
SCSM SCME
FSM
FEAM: Functional Entity Access Management

SCME-Control: SCF Management Entity
SCME FSM: SCF Management Entity Finite State Machine
SCSM: SCF Finite State Machine
Figure 7-34 SCF processing structure
Service Logic Program (SLP) is not illustrated in Figure 7-34. SLP communicates with
SCF FSM via internal interface. When an IN call receives a processing request sent
from SSF, an SCSM instance is generated and the related SLP is called. If the call is
initiated by the service logic, an SCSM instance is also to be generated.
SCF Management Entity, SCME executes all the operations relevant to management
function. SCME includes SCME-Control and several SCME FSM. SCME-Control
completes the interface function between SCSM and FEAM. Besides, SCME-Control
is also used for generating, invoking and maintaining SCF FSM single entity objects.
SCME-control creates SCME FSM and relies on it to execute actual processing of
management and monitoring functions (asynchronous with call processing). In this
way, SCME-Control simplifies the processing of SCSM, which in turn simplifies the
relevant processing of calls to realize the control over IN service logic flow.
SCSM state transition in IN call processing is illustrated in Figure 7-35.
(E3) Notice from SSF
(E8) Need Exception events 1. Idle

(E1) Invoke SLP
hand-off to SSF
(E2) Query SSF
(E6) Process failure
(E3)Processing finished
(E5) Request SRF
3. Connect to 2. Preparing
resource SSF instruction
(E7) Acquire resource (E9) Failure from SSF

(E10) Time out
4. User (E11) Continue SCF processing

Interaction
Figure 7-35 SCSM state transition
7-33
The SCSM state transition process is described below briefly:

Suppose there is one IN call from SSF, for example, when receiving 'Initial DP'.
SCSM obtains the key field of the service after analysis and then activates the
relevant service logic program to carry out the IN service processing. It enters state 2
'preparing SSF instruction'. The process is as shown in the following flow chart of
Figure 7-36.
1. Idle
Initial DP
Activate SLP process
2. Preparing SSF
instruction
Figure 7-36 SCSM state transition flow chart (state 1 → 2)
When SCSM is in 'preparing SSF instruction' state, it decides how to perform the
further processing as per the service logic instruction received. During the service
processing, additional information of the caller may be needed. This necessitates the
connection between SRF and the caller side to be established. SCSM transits to state
3 'connected to resource'. The process is as shown in the following flow chart of
Figure 7-37.
2. Prepare SSF
instruction
Request SRF
Allocation of
special resources
3. Connect to
resources
If there are spare SRF resources, the state changes to state 4 'Interact with user'. In
this state, SCF requests SRF to interact with the subscriber (for example, collects
additional information, broadcasts record notice). When interaction is completed, SCF
instructs SSF to disconnect the bearer link between SSF and SRF. If SCF has already
got all the information needed to instruct SSF to complete the call, service logic will
notify SCSM to continue SCF processing. Thus SCSM enters state 2 'preparing SSF
instruction'. The process is as shown in the following flow chart of Figure 7-38.
7-34
4. Interact with user
Continue SCF processing
Clear SRF connection
2. Prepare SSF instruction
If processing of SSF instruction that is issued to SCSM is finished, SCSM sends a

feedback to SSF. After this, it returns to 'idle' state.
7.5.4 SDF Processing Model
Below in Figure 7-39 is the SDF function model.
SDF data Exclusive control Database

management
management
SDF
Functional entity access management
SCF SMF SDF
Figure 7-39 SDF function model
SDF manages the data related to service logic process program, and is able to
access the other SDFs when executing SLPI. SCF can visit them in real time while
performing service logic of intelligent service supported by IN. SMF can manage the
data in SDF.
SDF has the following functions:
z Interacting with SCF to satisfy the request from SCF for data in SDF.
z Interacting with SMF to answer the data request initiated by SMF.
z Interacting with other SDFs to make the data distributed in the network is
completely transparent to SCF.
SDF comprises four parts: SDF data management, exclusive control management,
database and functional entity access management.
1) SDF data management
Offers functions needed for data storage, management and access in SDF. It has
SQL language as data operation language.
2) Exclusive control management
7-35
Guarantees security of data operation in SDF.

3) Database
It stores the data in SDF. It can be a large Relational Database such as Informix,
Oracle or Sybase, or, a real time database can be used for higher efficiency.
4) Functional entity access management
Offers message-processing functions needed for inter-communication between SDF
and other functional entities such as SCF, SMF or SDF. It also offers reliable message
transfer according to OSI seven-layer communication model.
7.5.5 SMF Processing Model
The SMF function model is illustrated in Figure 7-40 below.
SMSF/NMF
RM
SCEF SMSF NMF
SMAF MDB
ICF ICF
SSF SCF SRF

ICF ICF ICF ICF
ICF: Information Conversion Function NMF: Network Management Function

SMAF: Service Management Access Function SMSF: Service Management Sub-Function
MDB: Management DataBase RM: Resource Management
Figure 7-40 SMF function model
Service Management Function (SMF) includes IN Network Management Function

(NMF), Service Management Access Function (SMAF) and Service Management
Sub-Function (SMSF).
SMAF realizes Man-Machine Interface to provide the IN service administrators and IN
service subscribers with the function to visit SMSF/NMF.
SMSF realizes management of IN Telecom services and their instances applied by IN
Telecom service subscriber, which goes through the whole life cycle.
NMF performs management of physical network comprised of physical entities where
IN functional entities reside, which include management functions of network
resources configuration, equipment state monitoring, fault recovery, etc.
ICF completes information format conversion between multiple functional entities;
while Management DataBase (MDB) stores the service data, subscriber data, account
data, data of network configuration and its state.
7-36
7.6 Centrex Subscriber Call

C&C08 organizes related subscribers (for example, subscribers of an enterprise) into
a business subscriber group, named Centrex group. Each such group can have a
console set to assist the group's outgoing, incoming and intra-group calling. Also,
there can be a call center set up for helping multiple Centrex groups to make calls.
Besides, Centrex provides basic and supplementary service functions of PSTN, the
subscribers are provided with some services similar to PABX (refer to Figure 7-41).
Each Centrex subscriber has two numbers, one is the unified PSTN number, also
called a long number; another is the inner extension number used within Centrex
group, called the short number. It supports a maximum number length of eight digits.
C&C08 supports a maximum of 65535 Centrex groups and the capacity of each group
is determined only by the actual exchange capacity. Subscribers in a Centrex group
are no longer confined by geographical locations. With the spreading of SS7 signaling
network and IN network, Wide Area Centrex (WAC) is becoming more and more
popular.
A2
PSTN C &C 08
B2
C&C08
A1
C a ll c e n te r
C &C 08
B1
A3 B3 C e n tre x A
c o n s o le
Centrex A Centrex B Call center
A1 B1
Substitute for Centrex A console
Extension A2 Extension B2
Substitute for Centrex B console
A3 B3
Console Centrex A operator
Figure 7-41 Illustration of Centrex services
7.6.1 Centrex Services
Besides the basic services and supplementary services of PSTN, Centrex subscribers
also enjoy the following value added services of their own:
1) Subscriber outside Centrex group can make a direct-call to an extension (DID) .
2) When a Centrex subscriber calls a subscriber outside that group, he first dials
the Centrex access code, and then he can choose whether to hear (DOC2) or
not to hear (DOD1) the second dial tone before he dials the PSTN number.
3) Following call-authority levels are added to Centrex subscribers.
z Call-out in Centrex group
z Call-in in Centrex group
7-37
z Centrex group outgoing call

z Centrex group incoming call
z Subscriber in Centrex group can call the operator by dialing either the operator's
access code or its short number.
z Functions of Centrex operator
z Call queuing
z Assist Centrex subscribers to make group-outgoing calls, or transfer the group-
incoming call to the intended subscriber.
z Night service function
z Insert or interrupt a call when the called party is busy.
4) Call center function
A call center can be established to serve the whole network. This call center has
several public operator positions, which can be used by each Centrex group in the
network. Some Centrex groups may have no operator of their own, but they can be
managed by the Call Center. Call Center operator can perform the same functions as
the operator does in each Centrex.
7.6.2 Centrex Database Structure
There are three specially designed data tables for Centrex function, they are:
z Centrex group description table
z Centrex console description table
z Centrex out-group prefix description table
7.6.3 Centrex Subscriber Call Process
When a Centrex subscriber calls out, the called number will be eventually converted
to PSTN number for the number analysis. When calling out, the special call process
for Centrex group like checking call-out authority and number conversion are
performed. When calling in, checking call-in authority, queuing, discriminatory ringing
mode and transferring the call, are performed.
7-38
I. Centrex subscriber dials short number to make a call in Centrex group
Source SPM CCB Destination SPM
Call request
1.Identified as a Centrex call

2.Centrex call out authentication
Setup
Setup ACK
Dial tone
Information
Dial number
Information
3.Long short number conversion

4.Service authentication
Setup
5.Centrex call in authentication
6.Choose ring mode
Alerting Alerting
Ring
Ring back tone
Enter normal flow
Figure 7-42 Calls in the Centrex group
As illustrated in Figure 7-42, after receiving a call request, source SPM first identifies
whether it is a Centrex subscriber call by querying the subscriber data. If it is so,
checks the call-out authority. After collecting enough number of digits, CCB converts
the short number to long number by referring to the data configured in the long-short
number matching table. Then it analyzes again the long number and performs service
authority processing. After the destination SPM receives Setup(Establishment)
message, it queries the called party data to check call-in authority and determines the
ringing mode according to the setting in Centrex group description table and service
type.
7-39
II. Centrex subscriber dials to PSTN via access code

Call request
1. Call authentication
Setup
Setup ACK
Dial tone
Dial number Information
Dial number ．
． Information
．
2. Identified as Centrex call

3. Analyze out-Centrex prefix
4. Decide if to send second dial tone
Dial tone
Dial number
5.Number conversion
Dial number
Dial number
Set up
Enter normal flow
Figure 7-43 Centrex subscriber dial-out to PSTN
Centrex subscriber dials the group access code (for example, 9) to enter PSTN. As
illustrated in Figure 7-43, source SPM works in the similar way as it does in dealing
with the Centrex intra-group calls. During the number receiving, CCB makes out
whether this call is a Centrex group outgoing call by querying Centrex out-group call
prefix table. Also, it decides whether a second dial tone should be sent. It changes the
number by deleting the access code and then continues with the succeeding
connection.
III. Centrex console calls to subscriber of this Centrex group
The call process is illustrated in Figure 7-44.
7-40

Call request
Setup
．．．
1. Number conversion
Setup
2. Call in authentication
3. Check insertion rights
4. Insert
Alerting
Alerting
Figure 7-44 Centrex console call
The process of calling to a subscriber in Centrex group by Centrex console is the

same as that of an ordinary Centrex intra-group call. Figure 7-44 describes the calling
process of console insert, which is the same as that of Centrex intra-group prior to
CCB performing the number analysis. After that, when number analysis concludes
that it is console insert, CCB will send to the called party the setup message of
SETUP_CALL_INSERT type. After the insert-authority is verified, insert process will
proceed.
7.7 Data Service Call

When a packet terminal needs to communicate with another packet terminal in
PSPDN via ISDN, there are two kinds of interconnection modes available:
The first is X.31 CASE A, Circuit-switching access to PSPDN services.
The second is X.31 CASE B, Packet-switching access to ISDN virtual circuit service.
CASE A is to establish a transparent circuit-switched access connection via access
unit (AU) between ISDN and PSPDN. AU will complete the interconnection. This
connection can be established either by an ISDN subscriber or by AU. CASE B is to
establish packet-access connections via packet-handler (PH) of ISDN.
C&C08 ISDN supports both the above two modes.
For convenience in description, the symbols used in program flow are explained as
follows.
I. [ ]: contents in square brackets are the third layer messages
z The third layer Q.931 messages:

C: Connect
CA: Connect Acknowledge
CP: Call Proceeding
7-41
D: Disconnect
R: Release
RC: Release Complete
S: Setup
z The third layer X.25 messages:
Messages preceded by '[X.25]' means a X.25 third-layer packet
CA: Call Accepted
RST: Restart
CC: Call Connected
RSC: Restart Confirmation
CLC: Clear Confirmation
CR: Call Request
CLI: Clear Indication
IC: Incoming Call
CLR: Clear Request
II. ( ): contents in parentheses are the X.25 second-layer frames
GTEI: Group TEI (127)

A.B: X.25 layer 2 address (including both command and response)
SABM: Set Asynchronous Balanced Mode
SABME: Set Asynchronous Balanced Mode Extended
UA: Unnumbered Acknowledgement frame
UI: Unnumbered Information frame
I: Information frame
DISC: Disconnect frame
Layer 2 addresses marked (x, p) indicate that the code of Service Access Point
Identifier (SAPI) element of the frame address is packet type (SAPI = 16) information
as described in Recommendation Q.921. Layer 2 addresses marked (x, s) refer to
signaling type (SAPI = 0) information. Frames whose layer 2 addresses marked
(DLCI, p) indicate an ILAPD packet type information (SAPI=16) frame on Bd channel.
Data Link Connection Identifier (DLCI) comprises SAPI and Terminal Identifier (TEI).
7.7.1 Circuit-switching Access to Packet Network
I. Reference configuration
Figure 7-45 gives the configuration of PSPDN service access.
7-42
S/T
TE1
R S/T
X.25 DTE
N
TA
S/T T
D
S D A P
L S U S
L P
D
R S/T S A D
X.25 DTE N
L U
TA N
S/T T
TE1 C&C08
ISDN switches
AU: ISDN Access Unit

DSL: Digital Subscriber Line board
TA: Terminal Adapter
TE1: Terminal Equipment type I
NT: Network Terminal
DTE: Data Terminal Equipment
Figure 7-45 Reference configuration of circuit switching access to packet network
On S/T interface, X.25 DTE+TA is equivalent to packet TEI. ISDN only provides 64
kbit/s transparent physical path for packet calls between relevant PSPDN interface
and X.25 DTE+TA or TEI. Subscriber access to network via B-channel by two
connection modes: semi-permanent connection or immediate connection. In semi-
permanent connection, X.25 DTE + TA or TEI connects with the AU corresponding to
PSPDN. TA (if any) only completes the function of adapting subscribers to 64 kbit/s
rate on B-channel at R reference point. Packet network address code can be directly
used at terminal for packet calls, as shown in the lower part of Figure 7-45. When
immediate connection is used, X.25+TA or TEI connects with AU of PSPDN. But
before initiating Layer 2 and Layer 3 of X.25, connection between B-channel and AU
should be established via ISDN signaling protocol. See upper part of Figure 7-45.
II. Call connection process
There are two steps for call setup process: First is to establish a B-channel from X.25
DTE+TA to AU. This channel can be a leased line with semi-permanent connection. It
can also be established by using ISDN signaling protocol Q.931 via D-channel. In this
case, setup message of Q.931 includes the ISDN number of the PSPDN access
interface AU. Second step is to send a call request packet of X.25 protocol via B-
channel to complete the virtual circuit setup and data transmission.
1) Call-out connection
7-43
DTE TA DSL DCE
I (B) [X2.5 CR]

SABME (X, S)
　 (X, S)
UA
　I (X, S) [S]
　
I (X, S) [CP]
I (X, S) [C]
　
I (X, S) [CA]
Set up the path
SABM (B) between DTE and
AU
UA (B)
I (B) [X2.5 CR]
I (A) [X2.5 CC]
Data transmission stage
Figure 7-46 Call from ISDN DTE to PSPDN
As in Figure 7-46, when terminal DTE initiates a call request (CR), TA retains the call
request packet for the time being and establishes layer 2 link on D channel using
LAPD program. Then it uses I frame to transmit Q.931 messages. When TA receives
the Q.931 connect message, it sends connect acknowledge (CA) message, indicating
that connection between DTE and DCE in AU has been established. Then, TA
establishes layer 2 link of X.25 protocol via B channel and sends the retained X.25
call request packet. The confirmation of the receipt of the call connected (CC) packet
indicates the beginning of the data transmission state.
2) Call-in connection (from PSPDN to ISDN)
7-44
DCE DSL TA DTE
UI (GTEI) [S]
LAPD and Q.931 SABME (x,s) TEI=N

message
UA (x,s) TEI =N
I (x,s) [C]
I (x,s) [CA]
X.25 SABM (A)

layer 2 protocol UA (A)
I (A) [X.25 C]
X.25 I (A) [X.25 CA]
layer 3 protocol
Data transmission phase
Figure 7-47 PSPDN subscriber calls ISDN DTE
Figure 7-47 illustrates a call connection setup process in the case of a calling-in via
broadcast link. When network uses broadcast link to send setup message, TEI is 127,
which is assigned by TA. On receiving UA frame, TA sends Q.931 connect message.
After receiving the CA message, either by TA or by DTE, the X.25 layer 2 link and
X.25 layer 3 of B channel can be established directly.
7.7.2 Access to ISDN Virtual Circuit Service
It is called access to ISDN virtual circuit service to setup packet-switched connection

for packet terminals through ISDN packet-handler (PH). This is also called CASE B
mode by which packet terminal access to ISDN is established.
Logically, PH belongs to ISDN, but physically, it can also be put into the same PSPDN
node. ISDN can transmit packet data on B channel or D channel. Through D channel,
signaling as well as data can be transmitted. When SAPI of D channel on layer 2 is 0
(SAPI=0), D channel transmits signaling only; When SAPI is equal to 16, D channel
transmits packet data. D channel data transmission applies to situations in which
multiple low-bit-rate packet terminals are connected to one interface to communicate,
while B channel packet data transmission applies to the situation with high capacity
packets.
I. Parameter configuration
Figure 7-48 illustrates a configuration of accessing to ISDN virtual circuit service

using B channel and D channel. When using B channel, C&C08 Exchange offers
packet-handling ability. X.25 protocol link layer and network layer protocol are
transmitted on B channel. To setup B channel connection between X.25 DTE+TA and
PH interface: It requires that PH has the function of standard X.25 link & the network
layer and the function of physical layer & of rate adapting.
7-45
S/T
TE1
R S/T X.75
X.25 DTE N Or internal protocol
TA
T
S/T P
D S
S P
H P
L
D
R S/T D N
X.25 DTE S
L C&C08
TA
N ISDN exchange
S/T T
TE1
Access via B or D channel Reference point
AU: ISDN Access Unit

TA: Terminal Adapter
NT: Network Terminal
DSL: Digital Subscriber Line Board
TE1: Terminal Equipment type 1
PH: Packet Handler
Figure 7-48 Parameter configuration for ISDN virtual circuit service
Note:
This figure is only one typical example among many feasible configurations. It is an auxiliary activity for
introducing various interface functions.
When using D channel, packet layer protocol of X.25 is transmitted on D channel. PH

port supports X.25 packet layer protocol. In this case, SAPI of LAPD link is 16 and it
can multiplex the logical channel on layer 3. When subscriber has multi-point access
configuration, TA or TE1 can have more than one TEIs and network must support
multiple LAPD logical links (SAPI=16) to work simultaneously on layer 2.
II. Connection between PH and ISDN Exchange
PH accesses the ISDN Exchange via one or more PRIs (30+D). The connection
between PH and C&C08 ISDN Exchange is as shown in Figure 7-49. The section
related to processing of signaling on DSL board is not described. Each DSL board
has eight 2B+D interfaces. When D channel is used for communication, the eight 16
kbit/s D channels (D16) are multiplexed into one 64 kbit/s Bd channel that is
established and released as per necessity. To make it simple, only one DSL case is
given in Figure 7-49.
There are two kinds of physical interfaces between PH module and C&C08 ISDN
Exchange: (a) HDLC interface for communicating with the control station. PH
communicates with control station via a HDLC link. (b) (30+D) PRI connected with the
7-46
circuit switching section of C&C08 ISDN Exchange. All channels (excluding

synchronization channel) in the multiple PRIs can be divided into:
D64 channel: signaling channel for B channel call control. Layer 2 protocol is LAPD,
and layer 3 protocol is Q.931. When there are many PRIs, a specific PRI D64 channel
can be assigned as the signaling channel. D64 on the other PRIs can be reserved or
used as B channels.
Data channel (B channel): There are 30 B channels on each PRI. According to
working protocol on each channel, they can be divided into:
1) X.25 channel: Semi-permanent connection can be established by data
configuration in BAM.
2) Bb channel: Connect dynamically through Q.931 protocol. Bb channel is a part of
the B channels, which is used to transmit UNI packet data transparently.
3) Bd channel: Dynamically connected through Q.931. Bd channel is a part of B
channel, which is used to transmit packet data on D16 channel in UNI in
multiplexing mode. One Bd channel is used to transmit all D16 channel packet
information on one DSL board. Bd channel is dynamically established when
required. When a subscriber of a DSL board needs D16 channel for packet
communication: First, a Bd channel from DSL to PH must be established, then
packet data of all the packet terminals connecting to this DSL is transmitted via
this Bd channel. When all packet communications via D16 channel on the DSL
board are over, PH disconnects this Bd channel.
Bd and Bb channels are both controlled by PH uniformly. PH dynamically adjusts the
number of these channels.
Note:
D16 means 16 kbit/s D channel, D64 means 64 kbit/s D channel

C& C08 ISDN Exchange
DSL
MPU
2B+D
CPU LAP Multiple PRI
TE
Bb D64
TE
Bb Switching
 PH
network
BD
X.25
To PSTN
FH Bd
D16
2B+D HDLC
Terminal
Figure 7-49 PH connection to C&C08 ISDN exchange
7-47
In Figure 7-49, C&C08 MPU board is the main control board of switching modules, in
charge of the functions such as call processing and resource allocation (for instance,
B channel resources). LAP board assists MPU to realize PHI function; processes
channel (D64 channel) protocol, and connects Bd and Bb channels. FH in DSL board
is a frame-handler, responsible for processing packet data of basic interface D16
channel.
III. Protocols on channels
There are four kinds of PH channels: D64, X.25, Bb, and Bd. The protocols operating
on them are different and are explained below:
1) D64 channel protocol
It is the signaling channel for the control of B channel calls. Data link layer
communication protocol is Q.921. Layer 3 protocol of D64 emerges from the revised
Q.931, which can adapt for the PHI needs. The message type, message format and
call processing are basically the same as that in Q.931. (In this Manual, it is still called
Q.931 protocol.) Packet communication on Bb channel needs to be established by
Q.931 signaling. It needs to be clarified here that when B channel is used, the
interface for channel identification information unit is identified as the other interface
(namely PRI) and the channel is identified by code instead of by time-slot mapping.
Terminal interface: TE1 DSL/MPU PH
Network layer: Q.931----------------Q.931 Q.931 --------- Q.931
Data link layer: Q.921----------------Q.921 Q.921 --------- Q.921
Physical layer: I.430 I.430 I.430 I.430
2) X.25 channel
PH can access PSPDN by ISDN Exchange via more than one B channel (we call it
X.25 channel) of many PRIs. Thus the ISDN subscriber directly can access PSPDN,
so that the costs on special lines are saved. That is, it saves the cost of the special
line connecting PH to PSPDN packet exchange. Layer 2 protocol on X.25 channel is
LAPB and Layer 3 is X.25 packet layer protocol (PLP). PH access to PSPDN is via
X.25 channel as shown in Figure 7-50.
PH MPU/DSL PSPDN
X.25PLP X.25PLP
LAPB LAPB
NT1 TA
Hardware Hardware G.961 V.24
Figure 7-50 PH access to PSPDN via X.25 channel
3) Communication protocol on Bb channel

When a subscriber or PH chooses B channel for communication, the Q.931 protocol
and internal protocol must be used to establish a B channel between the subscriber
and PH, at first. Then the packet data can be transparently transmitted on B channel,
which means the protocol on B channel is standard X.25 protocol (including LAPB).
C&C08 ISDN switching module provides only a transparent physical path between
TE1 and PH. The protocols are as follows:
7-48
Network layer: X.25PLP---------------- X.25PLP ----------------X.25PLP

Data link layer: LAPB ---------------- LAPB ---------------- LAPB
Physical layer: I.430 I.430 G.703 G.703 X.21
4) Communication protocols on Bd channel
When a subscriber or PH chooses D channel for communication, the Q.931 protocol
must be used to establish a Bd channel between DSL and PH, at first. Then packet
data of all the terminals and subscribers on DSL can be transmitted on this Bd
channel. ISDN switching module provides a transparent physical path between DSL
and PH.
Data link layer communication between DSL and PH adopts an internal protocol, the
revised LAPD, called ILAPD for the present. Its frame structure conforms to ETSI 300
099 and the communication process on it conforms to ETSI 300 125 (Q.921: LAPD).
Layer 3 is PLP. DSL completes LAPD processing: It converts LAPD frame with
SAPI=16 to the corresponding ILAPD frame, sends it to PH. It also converts ILAPD
frame from PH to corresponding LAPD frame and sends it to D channel.
Network layer: X.25PLP X.25PLP
Data link layer: LAPD LAPD ILAPD ILAPD X.25
Physical layer: I.430 I.430 G.704 G.704
IV. Call connection process
1) Connect using Bb channel

Call processing of Bb channel connection is completely the same as Q.931 'packet
communication procedure', as shown in Figure 7-51, Figure 7-52 and Figure 7-53.
When a subscriber or PH selects B channel for communication, firstly Q.931 protocol
and internal protocol must be used to establish a B channel between the subscriber
and PH, then packet data can be transparently transmitted on the B channel. C&C08
ISDN switching module provides only a transparent physical path between
DTE+TA/TE1 and PH.
The complete process of establishing a virtual call by ISDN virtual circuit service B
channel access (TE1 call-out) is as shown in Figure 7-51 below.
7-49
TE1 DSL/MPU
PH PSPDN/PH
SABM (X, S)
UA (X, S)
I (X, S)[S, BC=Packet type]
I (x, s)[s, bc=Packet type]
I (X, S)[CP]
I (x, s)[CC]
I (X, S)[CC]
I (X, S)[CA] I (x, s)[CA]
D16
Bb
SABM (B)
UA (B)
I B)[X.25RST]
I B)[X.25RSC]
I (B) [X.25CR]
I B)[X.25 CC] I (B) [X.25CC]
B Bb
(one of UNI)
Figure 7-51 Establishing a virtual call by ISDN virtual circuit service B channel access (TE1 call out)
In case of a call-out, the subscriber selects B-channel to establish the first virtual call.
To do this, the subscriber first applies to the network CCB for access to PH by Q.931
Setup message. DSL/MPU transmits this Setup message to PH via D64 channel.
Upon receiving this, PH allocates a spare Bb channel. Then switching module will
connect through the Bb channel and the B channel in UNI, the information of which is
notified to the subscriber by DSL/MPU. After the subscriber activates B channel, it
establishes LAPB on the B channel, and then calls-out according to X.25 PLP. If the
system cannot make calls on the B channel allocated by PH, for example, when
DSL/MPU thinks that UNI has no idle Bb channel, then DSL/MPU will reject the call
directly without notifying PH; When PH has no idle Bb to allocate, PH will reject the
call and notify DSL/MPU of it, which in turn notifies the subscriber TE1. When call is
rejected, subscriber may choose either to give up calling or to call-out on D channel.
During the calling-out course, subscriber's authority on call-out to PH module will be
checked. Also, the caller's ISDN address is filled into the setup message sent by
DSL/MPU to PH module, so that PH module can conduct ‘statistics’ and ‘charging’.
PH module also uses the caller address filled-in by DSL/MPU for caller authorization
check to ensure that only authorized ISDN subscriber is accessing the ISDN virtual
circuit service.
When B channel is already established between a subscriber and PH, the subscriber
need not perform Q.931 signaling protocol, but make X.25 call directly on this B
channel.
When calling-in, if the called party has not accessed the PH module yet, PH sends
Setup message to DSL/MPU requesting to access the subscriber. DSL/MPU uses
corresponding Q.931 message to notify the called subscriber who, then will reject or
accept the call according to its own configuration and state after receiving the call-in
notification. When the DSL/MPU, after interacting with the subscriber, decides to
receive the call on B channel, it will notify PH and instruct the switching module to
connect the appointed B channel and Bb channel. Then PH starts LAPB and sends
X.25 call-in packets.
7-50
channel access (call-in TE1) is as shown in Figure 7-52 below.
TE1 DSL/MPU PH PSPDN/PH

I(B) [x.25 IC]
SABME (X,S) I(x,s) [S,BC=Packet CH=Bbi]
I(x,s)[CP]
UA (X,S)
I(X,S) [S,BO=Packet]
I(X,S)[CP]
I(x,s)[CC]
I(x,s)[CC]
I(x,s)[CA]
I(x,s)[CA]
D
D64
SAMB(B)
UA(B)
I(B)[X.25 RST]
I(B)[X.25 RSC]
I(B)[X.25 IC]
I(B)[X.25 CA] I(B)[X25CA]

B Bb
(one of UNIS)
Figure 7-52 Establishing a virtual call by ISDN virtual circuit service B channel access (call-in TE1)
When calling-in, if the called number has accessed to a PH module, PH will call-in
directly on the established path. If the path has reached its upper threshold of capacity,
it will reject the call and won't call-in to ISDN TE1.
Call-clear includes X.25 virtual circuit disconnection and Q.931 (B channel)
disconnection. A virtual circuit of the subscriber can be disconnected when the
communication is over. After the subscriber disconnects all the virtual circuits, if no
new virtual call exists, LAPB link should be disconnected immediately and then B
channel should be disconnected by Q.931 protocol.
The complete process of TE1 clearing the last virtual call with ISDN virtual circuit
service B channel access is as shown in Figure 7-53 below.
7-51
TE1 DSL/MPU
PH PSPDN/PH
SABM (X, S)
UA (X, S)
I (X, S)[S, BC=Packet type]

I (x, s)[s, bc=Packet type]
I (X, S)[CP]
I (x, s)[CC]
I (X, S)[CC]
I (X, S)[CA]
I (x, s)[CA]
D16
Bb
SABM (B)
UA (B)
I B)[X.25RST]
I B)[X.25RSC]
I (B) [X.25CR]
I B)[X.25 CC] I (B) [X.25CC]
B Bb
(one of UNI)
Figure 7-53 TE1 clears the last virtual call with ISDN virtual circuit service B channel access
2) Connection using Bd channel

During B channel connection, DSL is equivalent to FH in ETSI 300 099. FH
implements the ETSI 300 099 Switched Bd-channel standard.
The complete process of establishing a virtual call by ISDN virtual circuit service D
channel access (TE1 call out) is as shown in Figure 7-54 below.
7-52
TE1 DSL MPU PH PSPDN
SABME(x,p)
UA(x,p)
D64
I(x,p)[x.25 RST]
I(x,s)[S]
I(x,s)[CC]
I(x,s)[CA]
SABME(DLCI)
UA(DLCI)
(DLCI)[x.25 RST]
(DLCI)[X.25,RSC]
I(x,p)[x.25 RSC]
I(x,p)[x.25 CR]
(DLCI)[x.25 CR]
I(x.25 CR]
(DLCI)[x.25 CC] I[x.25 CC]
I(x,p)[x.25 CC]
D16 Bd
Data transmission
Figure 7-54 Establishing a virtual call by ISDN virtual circuit service D channel access (TE1 call-out)
When calling-out, if the caller selects D channel, then he uses D channel with
SAPI=16 to send SABME (x, p). When DSL receives this frame, it responds with UA
(X, P) immediately. If Bd channel has not yet been established on DSL board, DSL
first starts Bd channel setup process. After PH responds, it selects a suitable DLCI
and sends SABME (DLCI) through the logical data link identified with DLCI on Bd
channel to PH. After PH receives it, it responds with UA (DLCI). Thus, logical
connection is completed. Then subscriber can perform a virtual circuit call on this
logical connection. If Bd channel has been established on DSL board, DSL board
directly selects a suitable DLCI to send SABME (DLCI) to PH by the established
logical data link path identified with DLCI. In this way, this virtual call setup is
completed.
channel access (call-in TE1) is as shown in Figure 7-55 below.
7-53
TE1 DSL
M PU PH PSPDN/PH
D64 I(x.25 CR]
I(x,s)[S]
I(x,s)[CC]
SABM E(x,p) SABM E(DLCI)
UA （ DLCI ）
UA(x,p)
I (x,p)[x.25 RST] I (DLCI)[x.25 RST]
I(x,p)[x.25 RSC]
I (DLCI)[x.25 RSC]
I(x,p)[x.25 CR] I (DLCI)[x.25 CR]
I(x,p)[x.25 CC]
I (DLCI)[x.25 CC]
I[x.25 CC]
D16 Bd
Figure 7-55 The first virtual call setup by ISDN virtual circuit service D channel access (call-in TE1)
When calling-in, if the subscriber has the ‘channel type choosing authority’, PH first
starts Q.931 signaling protocol and sends Setup message requesting DSL/MPU to
connect the called terminal. DSL/MPU then sends Setup message to the called
subscriber. If the subscriber chooses B channel, the call process is as shown in
Figure 7-55; If subscriber selects D channel, (for example, the UNI interface has no B
channel available), DSL/MPU sends a ‘connect message’ to instruct PH subscriber
requesting to call-in through D channel. PH clears the connection by a RELEASE
message (cause value = 7), instructing DSL/MPU and the subscriber that the call will
be completed on the established connection (D channel). PH releases call parameter
after receiving Release Complete message. At the same time, it starts Bd channel
setup process (if there isn't an established Bd channel on DSL between PH and the
called subscriber). After DSL/MPU responds to it, PH selects a pre-determined DLCI
and sends SABME (DLCI) to the DSL. The response of DSL to this massage with the
UA (DLCI) signifies the completion of the connection. Then PH sends X.25 call-in
packet to the called subscriber. After the subscriber responds to it, the virtual circuit is
established.
7.8 Connection Control Message List
I. Call setup state messages
ALERTING
CALL PROCEEDING
CONNECT
CONNECT ACKNOWLEDGE
PROGRESS
7-54
SETUP
SETUP ACKNOWLEDGE
II. Call Information state messages
RESUME
RESUME ACKNOWLEDGE
RESUME REJECT
SUSPEND
SUSPEND ACKNOWLEDGE
SUSPEND REJECT
USER INFORMATION
III. Call clear state messages
DISCONNECT
RELEASE
RELEASE COMPLETE
IV. Other messages
CONGESTION CONTROL
FACILITY
INFORMATION
NOTIFY
STATUS
STATUS ENQUIRY
7.
7-55

Call Processing

Uploaded by

Copyright:

Available Formats

Call Processing

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Call Processing

Uploaded by

Copyright:

Available Formats

What are the different types of calls discussed in the document?

What are the different types of calls discussed in the document?

What are the different stages in a basic call process?

What are the different stages in a basic call process?

Technical Manual

C&C08 Digital SPC Switching System Table of Contents

Chapter 7 Call Processing........................................................................................................... 7-1

Huawei Technologies Proprietary

Chapter 7 Call Processing

7.1 Introduction to Call Processing

C&C08 operating system

Figure 7-1 Call processing subsystem and its supporting environment

Communications between call processing system, OS and DBMS and between

Huawei Technologies Proprietary

7.1.1 Call Types

7.1.2 Basic Call Process

Huawei Technologies Proprietary

Source SPM Call control block (CCB) Destination SPM

Idle Idle Idle

1. Call source analysis

6. NNI/UNI signaling matching

Information (CLD) SetupAck

9. Number analysis change

Wait DB Data DBMS

14. Record the called location

15. Call in authentication

Overlapping 18. Hardware equipment seizure

20. Release control

Control party hooks on

Hook on Non control party hooks on

Figure 7-2 Basic call processing flow

Huawei Technologies Proprietary

7.2 Various Call Processes

7.2.1 Intra-office Call

I. Call initiated state

Processing of intra-office call is illustrated in Figure 7-3.

1) Report off-hook 2) Query subscriber data 3) Allocate DTMF receiver

Figure 7-3 Intra-office call I: call initiated

Huawei Technologies Proprietary

caller side is a tone-frequency one, a DTMF receiver is needed to collect the

II. Overlap sending state

III. Outgoing call proceeding state

IV. Call-receiving state

Processing of intra-office call in receiving state is as illustrated in Figure 7-4.

Huawei Technologies Proprietary

Caller 12 The called

1) First digit 2) Stop dial tone 3) Followed digits

Figure 7-4 Intra-office call II: call receiving

V. Call disconnect state

Processing of intra-office call in call disconnect state is illustrated in Figure 7-5.

1) Report called off-hook 2) Connect message 3) Connect message

Figure 7-5 Intra-office call III: conversation and call disconnection

Huawei Technologies Proprietary

7.2.2 Outgoing Call

I. Overlap sending and receiving state

1) Select an idle outgoing

Figure 7-6 Outgoing call: overlap sending and receiving state

Huawei Technologies Proprietary

II. Call receiving state