|
|
|
|
This instruction describes the MTELpage Configurations required to operate it in the QEOC centre which delivers messages by MTELPage and the MDS. Prior to this release of MTELPage, the MDS provided messaging for Springhill Comms Centre and MTELPage provided messaging for all other centres. The latest release of MTELPage combines the functionality of both systems to produce the best messaging for all the communications centres. The main purpose for routing messages from MTELPage to the MDS is to provide message throttling with non-essential messages and quicker SMS messaging to mobiles and messages to Hutchison paging networks for essential messages. Both the SMS and paging interfaces are directly connected to the relative carriers in the MDS rather than using dialup communications as used by MTELServe applications. The MDS also has redundancy and backup of resources which improves messaging performance over the older MTELServe applications.
MTELPage sends messages to the MDS via MTELRelay and PagerDEC applications. MTELPage inserts messages into the normal queue (que.mdb) and depending on the level of message interaction required it will send alerts to all the applications required to deliver the messages. In general messages created in the MTELPage application are destined for 3 types of carrier networks. The commercial Hutchison paging system, 3G SMS carriers and remote MTEL picocell paging systems. When these messages are created they can be delivered either by MTELRelay to the MDS system or they are filtered to the MTELServe applications to deliver the messages via standalone dial up interfaces. The new MTELPage 2012 provides functionality to deliver messages to all these carriers using one of four modes of operation. The overall message delivery is diagrammed below. The circles represent sockets running in the applications. There are responses from each interface such that if any part of the chain fails, MTELPage will receive a notification and re-route the messages back through the older MTELserve applications.
MTELPage has several modes of operation which are unique to MTELPage 2012. The messages can be send using the following modes;
These modes are configured with a single
registry setting called Page2MDS.
The other fixed settings for the four modes above are shown below and must be in capitals.
MTELPage provides the normal functions as it has in previous versions, however it now can send messages to the MDS in a more controlled environment then the current VisiCAD system. This is one of the main reasons for introducing MTELPage to the MDS environment. To fit in with the MDS master suite of databases MTELPage must convert the data flow from the MTELPage environment into the MDS environment. Both MTELPage and MDS route messages depending on tables of information which take a pager number and determine what networks the message must be sent to. Initially the pager is assigned a base network or home network. Every network has an associated network where the same message is repeated to increase the chance of the user receiving the message. In the MDS system, the pager number is the primary key and it points to a base network in which the message is delivered. If a network then has an associated network, the message is also routed to the associated network. VisiCAD sends messages to the MDS in this mode. Each message sent is for a pager and is assigned to a network in MDS User table. The Network table then uses the network from the User table to determine which associated networks the message is also sent. In MTELPage the user has the ability to send single message to pagers or pre-assigned and adhoc groups. When the message is to be delivered MTELPage looks up the pager number and determines what network it is to be sent to and assigns this network to the message in the queue. If there is an associated network then another message is generated for that network using the same pager number and message. If the message is for a group of numbers, the group is broken into its individual members and each member is then treated the same as an individual message. However in the MTELPage to MDS configuration, this would mean the associated messages in MTELPage would be duplicated by the associated messages in MDS. The new MTELPage 2 MDS flag indicates to MTELPage whilst generating messages to ignore associated networks when sending messages to the MDS. Only the base messages are generated and forwarded on to the MDS. The MDS then takes the individual pager numbers and assigns these to the networks and associated networks via the information stored in the SQL databases in the MDS. For this reason there may be some differences between the MDS and the MTELPage databases and the messages may not go to the intended networks as set up in MTELPage.
Traditionally the message expiry timer for MTELPage is 10 minutes. The idea is that messages older than ten minutes in the queue are too old to be useful. It guarantees no messages will be sent accidentally many hours later due to an application malfunction. However in this new system of using MTELPage to deliver messages in a throttled manner, has exposed this timer to be too short when sending very large group messages. There is a registry entry in the mtelpagesysTCP.mdb file called MessageExpireyLimit as shown below.
For very large groups this limit should probably be set to 20 or 30 minutes. PDEC releases a message every 10 seconds, so the queue will be updated approximately every 10 seconds for each message in a group.
|
|
|
This
setting can be found in the client logs "Relay" settings as shown
left. In this example it has been set to deliver every message to
the MDS system. When this setting has been introduced into the
registry the previous "Hutch Only 2 MDS" setting becomes defunct.