FreeCalypso > hg > themwi-smsc

comparison doc/Arch-design @ 4:da97e78a5586

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/Arch-design: document queueing architecture
author Mychaela Falconia <falcon@freecalypso.org>
date Sat, 23 Dec 2023 00:54:24 +0000
parents b084a9542471
children 8a7eb3d4570a
comparison
equal deleted inserted replaced
3:b084a9542471 4:da97e78a5586
664 664
665 SMSC_DELIVER_TO_PEER: request direction is from themwi-smsc-core to the 665 SMSC_DELIVER_TO_PEER: request direction is from themwi-smsc-core to the
666 registered RH for this peer. The request carries an SM (struct sm_record); 666 registered RH for this peer. The request carries an SM (struct sm_record);
667 the response carries success or failure. 667 the response carries success or failure.
668 668
669 2.6. Queueing architecture of ThemWi-SMSC
670
671 2.6.1. Queueing in themwi-smsc-core
672
673 While every SM, active or historical, is stored in PMS, only active ones are
674 also held in RAM-based queues by themwi-smsc-core. There are many queues,
675 organized by SM destination:
676
677 2.6.1.1. Queues of SMs waiting to be delivered to SMPP peers
678
679 There will be a separate queue for each upstream or downstream peer, or more
680 precisely, one queue for the single upstream peer and one for each downstream
681 peer. Each peer is another SMSC somewhere else in the world, and each queue
682 holds messages which need to be transferred to that other SMSC.
683
684 When the process that serves as the RH for delivery to a given peer is
685 connected, the corresponding queue will be drained by themwi-smsc-core
686 transferring the SM at the head of the queue to the RH via SMSC_DELIVER_TO_PEER
687 request. Only one such request will be outstanding at any given time to a
688 single RH; once the RH responds to this SMSC_DELIVER_TO_PEER request, completing
689 that elementary exchange, themwi-smsc-core will discharge the SM at the head
690 and proceed to the next one in the queue, doing another SMSC_DELIVER_TO_PEER
691 exchange on it, and so forth.
692
693 2.6.1.2. Queues of SMs waiting for MSISDN-to-IMSI resolution
694
695 There will be a hierarchical structure of queues for this function:
696
697 * The top-level MSISDN-to-IMSI lookup queue will have one entry for each
698 _different_ target MSISDN in need of resolution;
699
700 * Under each unique target MSISDN entry in the just-described queue, there will
701 be a subqueue of individual SMs addressed to that MSISDN.
702
703 When the IMSI resolver RH is connected, themwi-smsc-core will take the MSISDN
704 at the head of the to-be-resolved queue and send it to the RH in a
705 SMSC_MT_FIND_IMSI request. When the RH responds, all SMs that are queued under
706 that MSISDN get their dest_imsi filled in, and are moved to the next queue
707 described in section 2.6.1.4.
708
709 2.6.1.3. Cache of recently completed MSISDN-to-IMSI lookups
710
711 To avoid many repeated queries resolving the same MSISDN to IMSI rapidly back
712 to back, particularly in the case of additional SMs to the same recipient (e.g.,
713 segments of a long message) arriving just after the initial MSISDN-to-IMSI
714 lookup completed and removed the target MSISDN from the queue, there will a
715 cache of recently resolved MSISDN-to-IMSI mappings. The time duration of how
716 long a cached lookup result will be considered valid will be configurable - it
717 is a trade-off between efficiency under high message load vs allowing
718 administrative changes in the mapping of subscribers (association between phone
719 numbers and physically issued SIM cards) and letting them take effect reasonably
720 quickly.
721
722 2.6.1.4. Queues of SMs waiting for final GSM MT delivery
723
724 There will be two queues for messages in this state:
725
726 * The first queue holds MT-intended SMs which are still officially in the
727 custody of themwi-smsc-core;
728
729 * The second queue holds MT SMs that have been transferred into the custody of
730 themwi-smsc-gsmif via SMSC_MT_TRANSFER exchange, see section 2.5.4.1.
731
732 themwi-smsc-core will actively manage the first queue, seeking to transfer each
733 SM into the custody of themwi-smsc-gsmif and move it to the second queue. Once
734 a message has been placed on the second queue, themwi-smsc-core no longer
735 actively manages it - the SM is now a responsiblity of themwi-smsc-gsmif.
736 In good system operation, they get discharged when themwi-smsc-gsmif performs
737 an SMSC_MT_DISCHARGE exchange. However, if themwi-smsc-gsmif goes away, all SMs
738 on the second queue will be moved back to the first queue.
739
740 2.6.2. Queueing in themwi-smsc-gsmif
741
742 themwi-smsc-gsmif is the sw component responsible for accepting MO SMs from GSM
743 subscribers and for delivering MT SMs to them. The former task is very simple
744 (each received SMS-SUBMIT from GSM side turns into SMSC_REQ_SUBMIT), but the
745 latter function (MT delivery) is where the real work lies. Our design approach
746 is that themwi-smsc-core will transfer all destined-for-MT SMs into the custody
747 of themwi-smsc-gsmif as quickly as possible (without waiting for each SM to be
748 delivered in turn, unlike transfers to peer SMSCs via SMPP), and then
749 themwi-smsc-gsmif is responsible for the actual queueing strategy and scheduling
750 of GSM MT delivery attempts.
751
752 The details of queue structure and delivery attempt scheduling strategy in
753 themwi-smsc-gsmif remain to be determined; the current plan is to implement
754 other parts of ThemWi-SMSC first.
755
669 3. SMS communication via direct shell access 756 3. SMS communication via direct shell access
670 757
671 To be filled. 758 To be filled.
672 759
673 4. Interface to local Osmocom GSM network 760 4. Interface to local Osmocom GSM network