UE <--> CN connections in 3G

[Neels Hofmeyr]

Hi all,

this is diverting a mail dialog that started off privately to this list,
for the benefit of everyone.

You may have noticed that Daniel is working on IuPS (3G/UMTS data conns)
and I'm working on the OsmoCSCN, which is going to handle IuCS (3G/UMTS
voice calls).

There was still some puzzlement around connection IDs and how to reach a
mobile device (aka UE). In particular, which ID or information do I store
to identify the link to a UE, and how do I find a UE in case of paging?

First off, we're so far implementing a special case where we're using a
HNB-GW to demultiplex voice and data (IuCS and IuPS) from an hNodeB
(femto-cell). ASCII art to illustrate, view in a monospaced font:


    UE 1   <--> |hNodeB 1| <-->|HNB-GW| <--->  |CSCN or SGSN
                               |  1   |        |
    UE 2   <--> |hNodeB 2| <-->|      |        |
    UE 3   <--> |              |      |        |
                                               |
                                               |
    UE 4   <--> |hNodeB 3| <-->|HNB-GW| <--->  |
                               |  2   |        |
    UE 5   <--> |hNodeB 4| <-->|      |        |
    UE 6   <--> |              |      |        |


So, how does a CSCN know where to send a message for a given UE, and how
does it reach that UE?

Turns out the picture is more like this:

             . . . (hNodeB) . . .    (HNB-GW)
    UE1 <--> | Cell <--1--> [RNC] <------------> [CSCN]
    UE2 <--> |

Meaning that the hNodeB actually encloses an RNC (Radio Network
Controller) and a single radio cell. The HNB-GW does pretty much
"invisible" forwarding of the SCCP|SUA connection to the RNC. Each RNC has
a global RNC ID, and can manage N radio cells. In the hNodeB case, there
is exactly one cell behind the RNC, but the general case looks like this:


    UE1 <--> | Cell <-----> |RNC1 <------------> |CSCN
    UE2 <--> |              |                    |
                            |                    |
    UE3 <--> | Cell <-----> |                    |
                                                 |
                                                 |
    UE4 <--> | Cell <-----> |RNC2 <------------> |
    UE5 <--> |              |                    |
                            |                    |
    UE6 <--> | Cell <-----> |                    |


When a UE calls, the CSCN receives a User SAP link with a conn_id, and
simply routes the reply back to this link and conn_id. The reply goes
right back to the RNC, and the RNC knows which cell the UE is at.

The case where the CN contacts a UE is known as paging, i.e. the request
by the CN that the UE shall please establish a connection to the CN. The
CSCN may encounter different cases here: a User SAP link may have been
established and is still present, or no link is available (e.g. a link has
existed before but has been torn down due to a Reset by the RNC, etc.).

If the link is still valid, this manifests as: the struct
gsm_subscriber_connection still has a valid pointer to an osmo_sua_link,
and iu_tx() feeds the conn_id to this link to reach the UE.
(Note that the gsm_subscriber_connection struct does not yet have an
osmo_sua_link pointer. I will move the ue_conn_ctx into the
gsm_subscriber_connection struct in an upcoming commit.)

If, e.g. due to a Reset, the osmo_sua_link pointer has been cleared, the
CSCN or SGSN will ask the HLR: where has the last location update for this
IMSI been registered? Each RNC can manage several location areas, further
divided into several service areas, and once the HLR has identified the
service area where the UE is expected, the CSCN or SGSN can identify the
RNC by the global RNC ID and send the paging request in that direction.

A bit of pseudo struct code:

    struct gsm_network {

       llist of struct gsm_subscriber_connection:
       {
          {
             struct gsm_subscriber subscr {
                char imsi[GSM_IMSI_LENGTH];
             };

             struct {
                struct osmo_sua_link *link; /* point into an rnc struct */
                uint32_t conn_id;
             } iu;
          },
          ...
       };

       llist of struct rnc (does not exist yet) :
       {
          struct osmo_sua_link *link; /* upon link-down, clear the above */
          ...
       };

    };


So, IIUC, the global RNC ID resolved from the HLR info should identify the
path to a particular UE. The CSCN knows which RNC is behind which of its
local link endpoints. In our special case with an HNB-GW and when there
are several hNodeB instances behind the HNB-GW, the HNB-GW knows which way
to send a connection reply by the established SCCP|SUA link, or which way
to send a paging request by the RNC ID. The finer code details here are
not entirely known to me yet, but I hope that the answers will come
naturally or have already been implemented by Daniel ;)


If any questions, answers or comments emerge in your mind while reading
this, please don't hesitate and share!

Thanks,

~Neels

-- 
- 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: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160208/a7941b2f/attachment.bin>