This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi again,
Attached to this mail you can find a more practical example of what
I believe is the correct flow of primitives in a real-world location updating
procedure between a SGSN (or MSC) and the HLR.
As you can see, there are two linked invocations/transactions:
1) the actual location updating request (SGSN/MSC -> HLR)
2) the 'insert subscriber data' transaction that is triggered (HLR -> SGSN)
3) the complation of the location updating request after the insert subscriber
data has been completed.
It's actually quite "impressive" to see how much needs to happen for such a
relatively simple task.
The MAP-DELIMITER.ind is generated locally by the MAP-provider to the map user
to indicate that it has finished sending all primitives for one incoming TCAP
message/packet/pdu. It is used as a means of synchronization, to which the
MAP-User then typically responds with a MAP-DELIMITER.req which in turn
triggers the transmission of all queued primitives in a response message.
Regards,
Harald
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: map_loc_upd.ps.gz
Type: application/octet-stream
Size: 11793 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20100718/43b63359/attachment.obj>