GSUP: E-interface messages for inter-MSC HO

historical

Hi Oliver,

I've already spent some time on a first draft for the new messages we will need
to implement the E-interface via GSUP for inter-MSC handover. It would be
excellent if you could take over from what I have so far.

I placed the draft in osmo-msc/doc/interMSC_HO_GSUP_msgs.txt on my branch neels/ho:
http://git.osmocom.org/osmo-msc/tree/doc/interMSC_HO_GSUP_msgs.txt?h=neels/ho

Anyone else is also more than welcome to take a look and remark on anything
that might seem a bad idea, etc.

This is the result of me reading a MAP trace of two MSCs negotiating inter-MSC
handovers, and of reading the 29.002, 29.010,... specs. I'm not permitted to
freely share the trace, let me know if you need details.

The most interesting bits in the draft are

- the new message types
- the newly added IEs (see "Of which are newly added...")

The tasks for you would be:

- Spell out the protocol messages in common/chapters/gsup.adoc
- Implement the definitions in gsup.h
- Implement encoding and decoding, and tests

It is not so trivial to understand what goes with which message; maybe you
don't even need to know in detail? But if any info is still missing for you to
grok what's going on, don't hesitate to ask, as always.

Also interesting to figure out: Implement the IPA routing for which I added the
source_name and destination_name IEs: N osmo-mscs connected to one osmo-hlr
forward messages to each other via GSUP.

- Connect two GSUP clients (test programs?) to a running osmo-hlr instance, and
  to extend the gsup_server so that we can use the source_name/destination_name
  IEs to forward GSUP messages between the two clients. (I added these because
  I'm fairly certain there is no existing in-band IPA protocol bits that would
  allow such routing; but I only briefly skimmed it, wouldn't hurt if you could
  verify that again.) The aim is to have plain gsup_client API to allow me to
  "just send messages back and fort".

- The session_id/session_state: we still need to figure out how to avoid
  collisions in session_id numbers, as any peer may at any point re-use the
  same session_id. Vadim suggested using a TI flag that gets flipped between
  sender and receiver, but since there are more than two peers, I guess we
  should treat each session_id as subordinate to a Request's source_name. IOW,
  any peer owns the entire session_id number space itself for sending out
  Request message types, and a Response or Error message type echos this
  session_id back with the source_name then having become the destination_name;
  it is perfectly legal for two peers to use the same session_id and collisions
  are avoided by Request vs. Response/Error. Something like...

    MSC-A   MSC-B   MSC-B'
      ------->              FOO_REQUEST(source=alice, destination=bob, id=3, state=BEGIN)
      <-------              FOO_RESPONSE(source=bob, destination=alice, id=3, state=CONTINUE)
      ------->              BAR_REQUEST(source=alice, destination=bob, id=3, state=CONTINUE)
      <-------              BAR_RESPONSE(source=alice, destination=bob, id=3, state=CONTINUE)
      --------------->      FOO_REQUEST(source=alice, destination=fred, id=4, state=BEGIN)
      <---------------      FOO_ERROR(source=fred, destination=alice, id=4, state=CONTINUE)
      --------------->      END_REQUEST(source=alice, destination=fred, id=4, state=END)
      ------->              END_REQUEST(source=alice, destination=bob, id=3, state=END)

  (We could possibly omit the source_name in Response/Error message types,
  because the Requestor already knows the peer from sending out the Request;
  but for sanity, maybe rather always keep both names.)

  Does this make sense / am I missing something?

- And we need to make sure that we can freely re-use the session_id IE on the
  E-interface without conflicting with the Supplementary Services session_id /
  without confusing the gsup_client API.

Please create issues on osmocom.org for these tasks as you see fit.

There is no pressing need yet to get this done *right now*, I have yet to
complete the inter-BSC HO in osmo-msc before I can start using GSUP. But it
would be great to just build on working API once I need it.

I would be super grateful if you could relieve me of the burden of spelling out
these details. From the meetings I assume that sysmocom agrees; please manage
that, too, and let me know if any other tasks are more important...

Thanks!!

~N

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190114/1531ed43/attachment.bin>