Project

General

Profile

Actions

MulticastProposal » History » Revision 3

« Previous | Revision 3/4 (diff) | Next »
laforge, 03/16/2018 09:35 AM
add digraph


MulticastProposal

So far, we primarily have been thinking about replication of the current location of the subscriber across the network. This stems from the classic approach, where the UpdateLocation transaction is performed from MS via MSC to HLR, and then the HLR is inquired for every mobile-terminating transaction.

However, it is assumed that the number of location updates (either periodic, or due to change in LAC (particularly at people living between two networks) is larger than the number of actual mobile terminated long-distance calls or SMSs to that subscriber.

NOTE: This proposal does not cover provisioning of (static) subscriber data. It only adresses the routing query/response for mobile-terminated transactions.

Routing Request

So why not simply turn the problem upside down: Rather than replicating the current location of the subscriber to a master HLR or across the entire network: Flood the network with a routing request once such a long-distance transaction occurs.

Normal Case

This proposal suggests to use something like ARP or mDNS at the time a long-distance MT call/SMS is looking for routing information:
  1. the originating node (another autonomous GSM network, or the "gateway msc" interconnecting with the rest of the world) sends a multicast-query for a given MSISDN
  2. this query is flooded across all currently reachable autonomous networks
  3. the current serving network will respond with its IP address, either via unicast (or possibly via unicast, if other network members should keep caches?)
  4. the originator now knows where to send the SIP INVITE to

mDNS request flooded to all Autonomous Networks (AN)

mDNS response from current serving VPLMN

Abnormal Cases

Multiple repsonses

In case the called party subscriber has recently been bouncing between two or more autonomous networks, multiple of them will respond to the same multicast request. This is not a problem, if
  • all nodes have accurate time (NTP, gpsd, ...)
  • all responses include the timestamp when the given MSISDN was last active

This way the inquiring entity can simply delay for some time (1s?) and then use the response with the most recent timestamp

No response

If there's no response, the query should be repeated (it's UDP, after all...) after a time-out for a number of times e.g. 3 times. If still no response is received, "subscriber unreachable" is signaled to the originator.

back-haul failure

If the back-haul / interconnect between originator and serving network is down, there will be no response. But then, this is the same interconnect that would be used for voice, so this doesn't matter

Constraints / Requirements

  • the network has to support multicast transport/routing, which apparently tinc currently doesn't
    • could be added to tinc (doesn't seem like a complex task)?
    • could switch to n2n or other peer2peer VPN?
    • one could use application-layer routers and unicast, simulating a multicast network where really there isn't. Seems like a not so elegant solution, but could have advantages by using reliable protocols like TCP or SCTP

Topology Implications

Unlike other proposals, there is no mandated topology requirement for tihs protocol. It can work over star architectures, just as over mesh or tree networks, just as long as the multicast messages can be routed/forwarded.

Optional Extensions

If a caching logic similar to ARP caching is used on the client/inquirer side, one could use "ARP poisoning", i.e. unsolicited responses to pre-populate the cache and thereby return to the old "flood location update" mechanism.

This means this protocol doesn't mandate the "request location only as needed" paradigm, and it could even run a hybrid of both. So the network elements could determine themselves on a per-subscriber basis if the rate of transactions (SMS/call) currently is higher than the number of location updates.
  • if the num_transactions_per_time > num_loc_upd_per_time send unsolicited responses / "ARP poisoning"
  • otherwise, use the mechanism above, i.e. only answer to queries

This way the optimum (smallest) number of signaling is used, irrespective of the usage pattern of a given subscriber.

Files (0)

Updated by laforge about 6 years ago · 3 revisions

Add picture from clipboard (Maximum size: 48.8 MB)