This chapter describes the internal workings of the bearer box: communication with SMSC's and CSD routers, internal major modules and data structures, threads, routing, error handling in routins, how it deals with the client box registrations and errors with client connections, and queueing of messages inside the bearer box. The bearer box connects to the SMSC's in the configuration, and accepts UDP packets at a suitable port. It checks whether SMS messages are normal ones or WDP packets. It routes stuff to appropriate boxes, taking care of load balancing. It keeps unsent messages in queues (incoming and outgoing), in case of traffic jams. It keeps track of the other boxes (lets them register, notices when connections break, keeps track of heartbeats). The bearer box is implemented with several threads to simplify program design and to increase efficiency.

SMSC threads handle connections to the SMS Centers. One thread per SMSC. The thread is responsible for connecting and re-connecting the SMSC, using the appropriate protocol, be it EMI, CMD, SMPP or other. The thread receives messages from SMSC and puts them into Request Queue (see below). Likewise, it picks messages from Reply Queue that are sent via the SMSC it is connected to. CSDR thread (UDP thread) is similar to SMSC thread, but it receives WDP datagrams from CSD Router. If several CSD Routers are used, multiple CSDR threads are used. Box connection threads do all the data transfer with SMS and WAP Boxes. Thread picks all appropriate messages from Request Queue and send them to Boxes. Likewise they receive messages from Boxes and put them into Reply Queue, wherefrom the appropriate SMSC or CSDR Thread reads it. Main program keeps everything in control. It listens to new Box connection requests and creates new threads for them, listens to HTTP-service port for adminstrative commands and keeps a record of all boxes connected. To achieve this, it listens to 'heartbeat' of other threads, and does necessary actions when heartbeat stops. Mobile oriented SMS Messages are handled by the SMSC thread, which is connected to corresponding SMS Center. The received message is written, along with any necessary SMS Center specified extra data, into the Request Queue. Acknowledgement to the SMSC is not immediately sent (NOTE: This is the plan. Now the ACK is immediately sent) The SMS Message is then read from the Request Queue by one of the Box Connections, and after it has been successfully transferred to SMS Box, an acknowledgement is written into Reply Queue. If the SMS Box is not available, NACK is written into Reply Queue. The SMS Center thread investigates the Reply Queue and pulls the ACK/NACK message from the queue and sends it back to SMS Center (as noted earlier, this is the plan. Current implementation ignores these messages and sends an immediate acknowledgement) Mobile terminated SMS Messages are initiated by the SMS Box. It transfers the message into the bearer box via Box Connection. The appropriate SMS Center is determined by the Box Connection and the message is then added to the Reply Queue. As with ACK/NACK messages, the SMS Center finds the message from Reply Queue and sends it to SMS Center. However, the message is not removed from the reply queue until an ACK or NACK is received from the SMS Center (NOTE: Actually, the message is first removed, then send and if we crash during that time, tough). If a NACK message is received, the SMSC thread either retries later or sends it back to SMS Box via Request Queue and Box connection. This is currently left to the implementation of the SMSC protocol. If the message is sent successfully, an ACK message is put into requet queue to inform the original box that the message has been relied (NOTE: Currently no ACK/NACK is sent back to SMS Box connection) WAP message packet handling does not differ from SMS Messages, except that all messages from same WAP Terminal must be sent to same WAP Box as earlier, and likewise replies must be routed back to the same terminal (CSDR) The main thread is responsible for knowing which parts of the program still work. The other threads upkeep their personal 'alive' status (heartbeat) and the main thread checks that the other threads have not stopped responding. If the alive status has not been updated for too long a time, the main thread assumes that the other thread has died or is otherwise stopped, and the main thread does necessary actions to destroy or restart it. Likewise each Box Connection keeps their personal connection to SMS or WAP Box alive by listening to the heartbeat from the box. If it stops, the connection is usually considered as lost and the appropriate Box Connection dies. As bearer box only routes packets coming from SMS Centers and CSD Router, Box Connections are used to connect service providers. Each SMS and WAP Box connects the bearer box with TCP/IP socket. A new Box Connection thread is then generated to handle that specific connection. Alternatively, one SMS Box can be run as seperate thread in bearer box. This increases the message response time as no TCP/IP traffic is needed, but increases the total load of the bearer box. As a new connection is opened, the bearer box sends any common configurations to the SMS or WAP Box. That way only one configuration file is needed to be edited (NOTE: currently this is not supported, and each box reads its own configuration file). The bearer box can be monitored and configured via HTTP interface. The main program handles HTTP-requests. The bearer box has a simple way to balance the load between several SMS or WAP Boxes. Each Box Connection has a load level, which has been provided by the box it is connected to. If the load level is considerably higher than the lowest load level of the box connections of the same type (SMS or WAP), the box connection does not pick new requests from the queue until its load level has lowered (or the load level of other box connections have reached its level) (NOTE: Currently the load balance is left to thread system - messages are read as quickly as any thread can pick them from the queue) This queue handles all messages incoming from SMS Centers and CSD Routers. It is not a standard queue, but instead it has many comncurrent queues. All new messages are appended to its tail (exception: ACK/NACK notifications are put into head), and similarly messages are pulled from its head. However, threads pull the first message of the right kind, and so this violates the normal concept of the queue. Only Box Connections read messages from the queue. The actual reader is determined by the type of the message (SMS message versus WAP SMS or UDP) and load balancing methods (see above). Only SMSC and CSDR threads add messages to this queue. The reply queue is similar to request queue in its behaviour. New messages are appended to the end, but old ones can be read from any place. Acknowledgement messages are put into head, so that they read from the queue first. Messages to reply queue are added by the box connections. The appropriate box connection doing the append does the necessary routing logics to address the message to corresponding SMSC or CSDR thread. Messages from reply queue are read by SMSC and CSDR threads. They are identified by the SMSC or CSDR thread identification number, which is given to them when they are first created.