UE <--> CN connections in 3G

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 &lt;nhofmeyr(a)sysmocom.de&gt; 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