Page 1 Last updated: 28-Oct-11 — 4:36 PM
The database server is capable of serving a large number of subscribers under
strict performance requirements. The design of the network defines that remote
subscribers can be accessed using a satellite. A delay can be generated by:
(1) Computation time and
(2) Communication time.
Usage of satellite channels will contribute at least 0.25 second to every
transaction. A delay of 0.25 second in a telephonic environment is an acceptable
delay. However; this delay will grow significantly due to retransmission requests,
computing delays etc. The remote agent eliminates the communication delay of
the remote subscriber by moving the relevant data on a temporary basis to a
computer adjacent to subscriber. This solution increases the complexity of the
solution, as there is a need to avoid any conflict between the data hosted on the
database server and the data copied to the remote agent.
Page 2 Last updated: 28-Oct-11 — 4:36 PM
The Remote Agent task is to behave as the database server front end in the
remote site. The database server will be located in the Central Office. However,
the remote support can be given by:
The central office using direct accesses to the database server.
This solution suffers from long response time composed of communication time
and computing time. The advantage of this solution is in its simplicity, as no
special measures are needed to handle far sites.
Using a remote agent in the field as a database server agent.
This solution loosens the connection to the database server and allows remote
users connected via a satellite connection to get telephonic services in a
reasonable grade of service, but creates synchronization problems between the
remote agent and the database server.
The following chat presents the relationship between the database server and
the far users.
Page 3 Last updated: 28-Oct-11 — 4:36 PM
Migration to the Remote Agent
A subscriber is not committed to a specific Remote Agent. This proposal gives a
flexible solution that enables a subscriber to roam from one Remote Agent to
The following scenario describes the message flow between the Remote Agent
and the database server.
a. The first attempt to access a user record will generate a fetch fault
procedure in the Remote Agent.
b. The remote agent will access the database server retrieving the required
c. The database server will send a copy of the record to the database server.
The master copy is kept in the database server and the Remote Agent
gets a shadow copy.
This procedure is done only in case the subscriber’s record does not exist in the
Every record, even a replicated record, has only one “master” copy. The records
base is the database server. This is the main and only copy of the record.
The first request for a record in the remote agent will create a shadow copy of the
record. This shadow record will be an exact copy of the record (or specific parts
of it) that will be transferred from the database server to the agent.
The database server will keep per record the following indicators:
An indication that the record was copied to the agent and the agent identification.
Page 4 Last updated: 28-Oct-11 — 4:36 PM
A time stamp indicating the last time that the shadow record was sent to the
A checksum. The checksum will be used to indicate whether the master and the
shadow copies are synchronized. The checksum will be initiated to 0 when a
shadow copy is extracted.
The shadow record has a limited life cycle. The record will have to justify its
existence in the agent. The only reason for keeping a shadow copy in the agent
is real telephonic traffic that requires the information stored in this record. A
shadow record will stored in the agent with the following indications:
The expiration indicator indicates when the record will loose its right to exist. This
time is an adjustable parameter and is renewed every time that a record
participates in a call. For example, this time is defined to be 10 hours. A shadow
record was created exactly at 08:00 and the expiration time is the day after on
18:00. In case that there is no traffic, the record will be erased on 18:00.
However, if a record participated in a phone call that started on 10:30, the
Expiration time will be updated to 20:30. The expiration process requires the
agent to verify that the database server updated the indicators indicating that the
shadow record was returned to the database server.
The checksum is a counter that starts with the value 0 when the record is copied
to the agent. Every change to the record will increment the value of this field by
Read transaction on the Remote Agent
The agent will try to perform the transaction in the following scenario.
Page 5 Last updated: 28-Oct-11 — 4:36 PM
The agent checks the existence of the record in the agent. If it exists, the agent
returns the required value to the requestor and update the expiration time.
In case the record does not exit in the agent, it gets a shadow copy from the
database server, updates its internal data structure with the time expiration
stamp, and the checksum indicator is set to 0 and returns the requested value to
Write transaction in the Remote Agent (or update transaction)
In case there is a need to bring the record from the database server the agent
will perform a read process.
After the read process has terminated successfully or the record already exists in
the agent, the agent will perform the modify action. The modify will perform the
Change the record value
Increment the value of the checksum indicator by 1
Acknowledge the transaction to the requestor
Send an update of the transaction to the database server. There is no need to
wait for database server acknowledgement. The acknowledgment is unsolicited
with the subscriber transactions. The record will be sent with the transaction
The database server and the agents will periodically perform an audit. This audit
will evaluate the need to synchronize the agent with the database server. In
case the parties are synchronized, the audit will terminate until the check. In
case there is a need to synchronize the agent and the database server, the audit
process will perform the synchronization. The initiation of the audit process will
Page 6 Last updated: 28-Oct-11 — 4:36 PM
come from the database server. The following actions will be performed when
the agent receives an audit request:
The agent will sum the values of the agent checksums. The value will be sent
back to the database server.
Upon receiving the sum, the database server will calculate the sum of the local
checksums of the records indicated to be in the particular agent.
The database server will compare the results. An equal result indicates that the
entities are synchronized and the audit process can terminate.
The database server will create a list of record keys and checksums (per
subscriber a key + checksum). This list will be sent to the agent
The agent will compare the checksum of every record arrived from the database
server to the checksum stored in the local table. Any unequal value will force an
update of the record in the database server. During this phase, an
acknowledgement from the database server is required.
Database server transactions
Performing active transactions like “update” on the subscriber record that was
borrowed to the Remote Agent creates a problem. This problem may create an
For example, a replenishment request that adds globally free time to all
subscribers or specific subscribers that have a birthday in a certain day may not
be performed on the database server record while the shadow record is stored in
the Remote Agent. This problem can be handled in 3 alternative directions. The
following table presents the alternatives and a short list of advantages and
Page 7 Last updated: 28-Oct-11 — 4:36 PM
# Option Advantages Disadvantages
1 Keeping the modification request in Simple. Transactions are
a log until the record will expire from unlimited in time.
the Remote Agent and the
synchronization is The update can be
responsibility will be returned to the
needed done in an irrelevant
time (too late)
2 Broadcasting the DML request to Complicated The Remote Agent
the Remote Agent and performing is busy with non
the transaction in the Remote telephonic
Generate load on
3 Recalling the record from the Medium Some transaction
Remote Agent to the database complexity may be delayed. (Very
server and performing the DML rare)
request in the database server. A
forced expiration of the transaction
will return the shadow record to the
database server. The validity of the
record will expire as soon as the
current telephonic activity ends (if it
Page 8 Last updated: 28-Oct-11 — 4:36 PM