Cellular Network Infrastructure » Radio Access Network » OsmoPCU

I think it would be great if pespin and/or fixeria could also do some
research and the two of you discuss what kind of options exist to
proceed. I personally currently don't have the time to do a deep-dive
straight away :/

At least regarding RLC/MAC (TS 44.060), the newest spec seems to provide plenty of content regarding jumping to E-UTRAN: https://www.etsi.org/deliver/etsi_ts/144000_144099/144060/17.00.00_60/ts_144060v170000p.pdf

It also points several times to for E-UTRAN NACC related topics https://www.etsi.org/deliver/etsi_ts/136300_136399/136331/16.08.00_60/ts_136331v160800p.pdf

Some notes from TS 44.060:

a mobile station sends a PACKET CELL CHANGE NOTIFICATION message, it shall indicate the CSG cell as the target cell in the PACKET CELL CHANGE NOTIFICATION message using the 3G Target Cell Struct or E-UTRAN Target Cell Struct

For a multi-RAT mobile station supporting "CCN towards E-UTRAN, E-UTRAN Neighbour Cell measurement reporting and Network controlled cell reselection to E-UTRAN", the PACKET CELL CHANGE ORDER message may contain information on an E-UTRAN target cell; in this case, the establishment of channel(s) and subsequent measurement reporting are defined in 3GPP TS 36.331.

an E-UTRAN capable mobile station ordered to an E-UTRAN cell shall obey the PACKET CELL CHANGE ORDER message irrespective of whether the target cell is known or not known (see 3GPP TS 36.133).

In case of network controlled cell reselection to E-UTRAN, the procedure is regarded as succesfully completed when the mobile station receives an RRCConnectionSetup message in the target cell (see 3GPP TS 36.331).

The network uses the parameter E-UTRAN_CCN_ACTIVE on the BCCH (SI2quater) to indicate in the cell whether CCN is enabled for cell reselection towards E-UTRAN cells (including E-UTRAN CSG cells)

If E-UTRAN_CCN_ACTIVE is not provided or it indicates that CCN is disabled in the cell, the mobile station shall not follow the CCN procedures towards E-UTRAN cells. E-UTRAN_CCN_ACTIVE can also be individually sent to the mobile station in either a PACKET MEASUREMENT ORDER, a PACKET CELL CHANGE ORDER message or a PS HANDOVER COMMAND. In the latter cases, the setting applies in the target cell;
NOTE: It is not possible for the network to enable CCN mode towards individual 3G or E-UTRAN neighbour An E-UTRAN cell shall be identified by EARFCN, Measurement Bandwidth and Physical Layer Cell Identity.

If E-UTRAN Neighbour cells are reported, the type of report is specified by the E-UTRAN_REP_QUANT parameter and the maximum number of E-UTRAN reports in the message is specified by the parameter E-UTRAN_MULTIRAT_REPORTING. These parameters may either be broadcast on BCCH or sent to the mobile station in a PACKET MEASUREMENT ORDER message.

TS 44.060 8.8.3 "2)" and "3)" seems to implicitly state that only info for target GSM cells is sent to the MS. According to "1)", we can simply send a PKT CELL CHANGE CONTINUE without passing any information prior to it, and the MS should just jump to it, as I think we do right now for cells which we don't have information about (including EUTRAN cells, but needs to be tested in ttcn3).

Regarging GERAN to EUTRAN PS-Handover, there's a section about it in TS 44.060 8.10.3.3 GERAN A/Gb to Iu/E-UTRAN PS Handover. In there is also seems to indicate that we should not pass information of the EUTRAN cell through RLC/MAC (the other part of the answer is probably again in 3GPP TS 36.331):

The source BSS shall not send the mobile station unsolicited PACKET NEIGHBOUR CELL DATA messages in the old cell as system information corresponding to the new cell is sent to the mobile station in the new cell as described in 3GPP TS 25.331 (for PS handover to Iu mode) or as described in 3GPP TS 36.331 (for PS handover to E-UTRAN).

TS 44.060 11.2.3a "Packet Cell Change Notification" can describe wish to move to an EUTRAN cell:

E-UTRAN Target Cell : < E-UTRAN Target Cell Struct >> 
E-UTRAN CCN Measurement Report : < E-UTRAN CCN Measurement Report struct > >

< E-UTRAN Target Cell struct > ::=
< EARFCN : bit (16) >
{ 0 | 1 < Measurement Bandwidth: bit (3) > }
< Physical Layer Cell Identity : bit (9) >
< REPORTING_QUANTITY : bit (6) > ; -- Measurement Report for E-UTRAN target cell

< E-UTRAN CCN Measurement Report struct > ::= -- Measurement Report for E-UTRAN neighbour cells
< 3G_BA_USED : bit >
< N_E-UTRAN: bit (2) >
{ < E-UTRAN_FREQUENCY_INDEX : bit (3) >
< CELL IDENTITY : bit (9) >
< REPORTING_QUANTITY : bit (6) > } * (val(N_E-UTRAN + 1 )) ;

Measurement reporting for E-UTRAN Cells is defined in 3GPP TS 45.008.

11.2.4 "Packet Cell Change Order"

< E-UTRAN Target cell : < E-UTRAN Target cell IE >>
Individual Priorities : < Individual Priorities IE >> 

So for the EUTRAN case, it seems we only need to somehow validate if that EUTRAN cell is acceptable for the network to let the MS jump into it, and then simply send PAcket Cell Change Order with that same E-UTRAN Target Cell ID we received in "Packet Cell Change Notification". Or simply go directly to sending "Packet Cell Change Continue" without providing anything, and I think MS should move to that new EUTRAN cell anyway, which is what we do now iirc.

general context note: The provision of GERAN system information for fast cell change
(from any source RAT, whether GERAN, UTRAN or EUTRAN) is only needed because in GERAN
it takes ages for the MS to sit on the BCCH and receive all those SI.

Presumably the full SIB acquisition in EUTRAN is ultra-fast, and hence it's not required
to provide it via the old cell. In fact, it would probably slow it down, as transmitting
that data over GERAN is slow...

ACK to laforge , I also thought the same regarding why sysinfo passing is not needed for EUTRAN.

Regarding PS-Handover from GERAN to E-UTRAN, it seems there's some containers:

NAS Container for PS Handover
This information element contains the NAS information needed by the mobile station when performing DTM Handover
to A/Gb mode and is defined in sub-clause 12.43.

PS Handover to E-UTRAN Payload
This information element contains a DL-DCCH-Message including a RRCConnectionReconfiguration message (as
defined in 3GPP TS 36.331) containing the information needed by the mobile station when performing PS Handover to
E-UTRAN. This information element is defined in sub-clause 12.45b.

Maybe that's passed to PCU inside RIM?

Or simply go directly to sending "Packet Cell Change Continue" without providing anything, and I think MS should move
to that new EUTRAN cell anyway, which is what we do now iirc.

I have had a look at the CSN.1 description of PacketCellChangeOrder now. It seems simple at first, as soon as one notes the sub structs on the next page. I think it would work to send a PacketCellChangeOrder, but (after more spec reading) I think sending a PacketCellChangeContinue is the more appropriate way.

At first I thought PacketCellChangeContinue (see 3GPP TS 44.060, Table 11.2.2a.1) would not work since it's information elements only specify ARFCN and BSIC (GERAN). There is no way to reflect a proposed EUTRAN cell. At the first look this seems to be a problem, but in 3GPP TS 44.060, section 5.5.2.3 I find the following:

"The ARFCN for BCCH and the BSIC identifying a GSM neighbour cell shall be included in the PACKET CELL
CHANGE CONTINUE message in case a set of PACKET NEIGHBOUR CELL DATA messages referred by the
corresponding CONTAINER_ID value was sent for that cell without ARFCN and BSIC provided."

This fits in the over all picture. When we propose an EUTRAN cell in PacketCellChangeNotification, we won't get PacketNeighbourCellData from the network, so the PacketCellChangeContinue message does not reflect the proposed cell in this particular case. And it also means that PacketCellChangeContinue does not need to specify EUTRAN (or UTRAN cells).

So I think pespin 's assumption is correct. I am currently testing this in TTCN3. As far as I can see OsmoPCU does not react properly with a PacketCellChangeContinue message when we propose an EUTRAN cell in PacketCellChangeNotification. I think we were misinterpreting the code in nacc_fsm.c. In handle_retrans_pkt_cell_chg_notif() it appears to be the case that we send the PacketCellChangeContinue, regardless if we are able to parse the PacketCellChangeNotification, but that seems to be valid for retransmissions only. When the FSM starts in st_initial() and there is an EUTRAN cell in PacketCellChangeNotification, the parsing fails and the FSM is terminated. Presumably this also explains that changing to EUTRAN is slow at the moment.

I have now bent the TTCN3 test and the FSM so that we send a packet PacketCellChangeContinue in response but that still requires some clean up. In any case, I think we are on the correct path now.