Umtrx meeting in Paris :)

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/UmTRX@lists.osmocom.org/.

stephane at shimaore.net stephane at shimaore.net
Wed May 8 13:09:58 UTC 2013


Hi Alexander,

> Could you describe the communication between the OpenBTS and the "SIP
> entity" in more details? I want to better understand how could we
> avoid changes in the OpenBTS by introducing this entry.

The goal is to minimize changes in OpenBTS, really. The transfer of calls
from one cell to another (=handover) would be handled by the "SIP entity";
the goal is that OpenBTS only has to be able to establish and tear down
a call/channel between the GSM side and the "SIP entity". (This means
OpenBTS stays a BTS-like entity, it doesn't become a call-switching system.)

Call flow in that case could look as follows for a handover (MS is
associated with BTS1 at start of call, handover to BTS2; in the right
column I indicated the equivalent BSSMAP messages):

MS           BTS1           BTS2            "SIP-entity"
|             |             |                     |
|             |             | <- INVITE --        | (Handover Request)
|             |             | -- 180 (TCH,HRef) > | (Hand.Req.Ack.)
|             | <- INFO? (TCH,Handover Ref) --    | (Handover Command)
| <- RR H-Cmd |
| --- RR Handover Accept -> |
|             |             |   -- 200 -->        | (Handover Detected)
| - RR Handover Complete -> |
|             |             |   -- INFO -->       | (Handover Complete)
|             | <- BYE (handover) --------------  | (Clear Command)
|             | -- 200 ------------------------>  | (Clear Complete)

Basically we establish a new "call" (SIP session) with BTS2, notify BTS1
so that it triggers the Handover Command, BTS2 connects the call, and
eventually we disconnect the call on BTS1. After the handover BTS1 is no
longer in the call path at all.

The issues I have are related to "what happens in case of failure" and
how to encode this in SIP; for example in the above call-flow the first
INFO message ("Handover Command") could instead be a BYE message, but I'm
not sure what the behavior of the MS is if the handover fails, so it's
safer to use an INFO message in that case.
Also I'm not sure how things work when the network asks the MS to change
cells outside of a call (if I understand properly this is called handoff):
is this also accomplished using RR Handover messages?
In that case we shouldn't use an INFO or a BYE message, we need to use a
NOTIFY (or PUBLISH) message instead.


The PUBLISH addition for Measurement Reports is a related but separate
idea, this is to externalize the decision-making for handover.
"PUBLISH" SIP messages would be generated when OpenBTS receives a RR
Measurement Report:

MS                              BTS
|                               |               |
| -- RR Measurement Report ->   |               |
|                               | -- PUBLISH -> |

This would require a separate software entity that
handles these messages, implements the decision algorithm, and triggers
handover from an MM and a CM perspectives.


Overall in this approach OpenBTS (or some kind of A-bis-over-IP/SIP
translation system as you mentioned) would exchange:
- REGISTER messages with a registrar network (which plays the role of
  HLR/VLR/EIR);
- INVITE messages with the "SIP entity"; the "SIP entity" deals with
  peer-to-peer communication, in-call handover control, ..;
- PUBLISH messages with some third entity, which deals with resource
  management and uses the "SIP entity" to implement handover.

S.




More information about the UmTRX mailing list