1 / 18

Welcome SMS

Welcome SMS. Welcome SMS in Erlang. Experiences of Rapid Deployment in a GSM network. The Requirement. Send out SMS messages to One 2 One customers when they arrive in a foreign network. Don’t send them any more messages for at least two weeks.

alma
Download Presentation

Welcome SMS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Welcome SMS Welcome SMS in Erlang. Experiences of Rapid Deployment in a GSM network

  2. The Requirement • Send out SMS messages to One 2 One customers when they arrive in a foreign network. • Don’t send them any more messages for at least two weeks. • Different messages depending on destination Country. • “Marketing” usable GUI configuration. • Option to send messages to roaming customers when they arrive in the UK. • Ultra reliability not a hard requirement • Except NOT sending multiple messages

  3. The Timescale • 8 (yes, 8) weeks from start of design to launch of service.

  4. Access to Customer Behaviour? • Monitor all international c7 signalling links. • Extract contents of MAP messages: • Where is the customer? (VLR Address) • Whose customer is it (IMSI) • Who should receive the SMS? (MSISDN) • VLR address and IMSI are in Location Update, MSISDN is in Insert Subscriber Data. These messages can even take different physical routes...

  5. Business Logic • Decide which message to send • Different depending on class of customer (prepay, postpay, wholesale) • Different depending on destination Country • Different for inbound roamers • Have we sent them one already in this country? • Have they elected not to receive these messages

  6. Operational Requirements • Integrated with existing alarm management system (SNMP Traps) • Generate statistic reports of system activity into existing stats database. • Load balancing between SMS service centres • Ability to on the fly reconfigure which SMS service centres are active and the load balancing between them.

  7. Design Options • Commercial c7 probes to do automatic correlation of all messages for a particular activity. • Best supplier delivery time longer than entire project duration. • Time taken to integrate.. Who knows. • Option to exercise Synergy across T-Mobile International group. • Several useful design ideas shared. Again, timescales not lined up • Standard commercial systems - expensive, don’t meet all requirements, integration time huge

  8. Design Options 2 • Use Erlang? • But what about c7 probes? • Possibility to use standard test set (MPA 7400) to extract all c7 messages as raw data and send out as UDP • Two spare (but old) 4 CPU Sun machines about to be de-commissioned • Lead times of all elements OK. Now to work...

  9. Design Overview SMS Service Centres Customer Database Also Erlang! TCP (Internal Protocol) TCP (GIP Protocol) Erlang - A Erlang - B UDP c7 UDP c7 C7 Probe C7 Probe

  10. Erlang Nodes SMS Service Centre wsms_logic@bruce wsms_logic@burns sms sms db_read db_read inets mnesia stats snmp inets mnesia stats snmp Customer dB Failover logic logic correlator@bruce correlator@burns Failover correlator correlator gn_agent1@bruce gn_agent2@bruce gn_agent1@burns gn_agent2@burns C7 decode C7 decode C7 decode C7 decode Bruce Burns Active Standby UDP c7 messages

  11. Some screenshots

  12. Some screenshots

  13. Some screenshots

  14. Problems encountered • Bug with restart of one process starting up too many sms sending processes. • LAN Latency - both for UDP and dB reads. • Fixed by tuning concurrency and timeouts. • One module not permanently loaded in the customer Database. • Scanning an Mnesia table to delete some rows is pretty heavy..

  15. What else have we been up to? • Oracle Call Interface Binding to Erlang • Multithreaded Driver • Pools of Sessions • Decent Performance (> 1000 selects per second) • 1500 lines of C (so far!) • Garbage collection of stale handles

  16. What else have we been up to? • Oracle Call Interface Binding to Erlang N = “447956123456”, F=fun() -> case oci:exec(“select name, balance from cust where telno = :e”, [N]) of [{Name, Amount}] -> A1 = Amount - 10.0, oci:exec(“update cust set balance = :e where telno = :e”,[A1, N]) [] -> oci:abort(“Customer not found”) end, oci:transaction(Connection, F).

  17. What else have we been up to? • Generic “behaviour” for tcp/ip clients • link management (using heartbeats) • simple callbacks for protocol implementation • model is all transactions multiplexed down 1 socket • time taken to implement new protocol down to a few days • Call Data Record - record and playback

  18. What else have we been up to? • The Original Project used to justify the use of Erlang never got into service. All hardware has been re-deployed for other Erlang applications!

More Related