Project

General

Profile

Actions

Feature #6044

closed

OsmoSGSN - Feature #5759: Support for Mobility between SGSN (2G/3G) and S-GW (4G)

Extend osmo-pcu and related TTCN3 tests so that PacketCellChangeNotification is tested with 3G/4G cells

Added by dexter 10 months ago. Updated 8 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
05/25/2023
Due date:
% Done:

100%

Spec Reference:

Description

At the moment we only test PacketCellChangeNotification (which triggers the RAN information request cascade) with 2G cells. Also osmo-pcu is currently only able to understand PacketCellChangeNotification requests that contain 2G cells as well.

In order to improve NACC/CCO support towards 3G and most importantly 4G we must extend the TTCN3 tests and osmo-pcu. On the TTCN3 testsuite this essentially means to complete the missing bits in the message records of RLCMAC_CSN1_Types.ttcn. Once that is done we can complete the testcases and use those to complete osmo-pcu. There we mainly have to take care that the 3G/4G target cell information is properly encapsulated in RIM messages. There may also be missing bits in the reverse path when the cell information is encapsulated in PacketNeighbourCellData messages and passed back to the MS/UE.

Actions #1

Updated by dexter 10 months ago

  • Status changed from New to In Progress
Actions #3

Updated by dexter 10 months ago

  • % Done changed from 0 to 10

The PacketCellChangeNotification record definitions in RLCMAC_CSN1_Types.ttcn are incomplete. There are several release extensions missing which we need. At the moment only GERAN cells are supported in the request. We need to add support for GERAN cells, which were added in release 11 (as far as I can see). So we need to upgrade the message record up to release 11 (there are gaps, we won't have to work through 11 releases). For a start I have added the extensions for release 6:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/32995

Actions #4

Updated by dexter 9 months ago

  • % Done changed from 10 to 20

We now have extensions we need in PacketCellChangeNotification. So we can now define a template with an EUTRAN target cell and try sending those.

We would normally expect (multiple) PacketNeighbourCellData messages from the PCU. Those messages should contain the system information of the trarget cell. But as it seems this message does not support EUTRAN cells either. In 3GPP TS 44.060 Table 11.2.9e.1 one can see that the struct may contain an ARFCN and a BSIC. There is no reference to EUTRAN at all. This also might explain why RIM limits the NACC RAN INFORMATION REQUEST to EUTRAN to GERAN requests only.

As it seems the only meaningful way to continue here is to go ahead and send a PacketCellChangeContinue request right away. (After probably at least checking if the target cell even belongs to the network we operate)

Also I wonder why PacketNeighbourCellData seems not to specify EUTRAN cell information. An exploitation that comes to my mind would be that an MS that is registered on GERAN basically has the EUTRAN transceiver free for monitoring EUTRAN cells. For other GERAN cells this is different. There is not much room for monitoring other GERAN cells, so it is better to request the system information from the network rather then receiving them over the air. But this still does not explain why there is a RAN INFORMATION REQUEST from EUTRAN to GERAN specified. An UE that is registered with EUTRAN should have its GERAN transceiver free for monitoring. So why is there a need for requesting system information from EUTRAN but not from GERAN?

Actions #5

Updated by laforge 9 months ago

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 :/

Actions #6

Updated by pespin 9 months ago

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.

Actions #7

Updated by laforge 9 months ago

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...

Actions #8

Updated by pespin 9 months ago

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?

Actions #9

Updated by dexter 9 months ago

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.

Actions #10

Updated by dexter 9 months ago

  • % Done changed from 20 to 60

I have now added two tests to increase the test coverage for NACC. The first test the behavior when when an UTRAN cell is proposed. The second test, tests what happens when an E-UTRAN cell is proposed.

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33539 PCU_Tests: verify that PacketCellChangeContine contains an ARFCN and BSIC
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33540 PCU_Tests: test NACC procedure with UTRAN and E-UTRAN cell

In Osmo-PCU it is now detected when an E-UTRAN or an UTRAN cell is proposed and if so, we take the short route and send PacketCellChangeContinue immediately.

https://gerrit.osmocom.org/c/osmo-pcu/+/33538 nacc_fsm: Add support for NACC with UTRAN and E-UTRAN cells

I didn't add any plausibility checks for the proposed cell now since I wonder if this is really needed. If everything is right, then the UE should only propose cells where it should be able to roam to.

Actions #11

Updated by dexter 9 months ago

  • % Done changed from 60 to 70

The patches that extend the TTCN3 testsuite also tests NACC with UTRAN and EUTRAN cells are merged. The osmo-pcu still require a bit more review before we can merge them.

Actions #12

Updated by dexter 8 months ago

  • % Done changed from 70 to 80

Unfortunately there the last patch broke the Testcases TC_nacc_outbound_pkt_cell_chg_notif_dup* and TC_nacc_outbound_pkt_cell_chg_notif_twice*.

The problem seems to be related with the detection of duplicates, the following patch fixes that:
https://gerrit.osmocom.org/c/osmo-pcu/+/33844

Actions #13

Updated by dexter 8 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 80 to 100

The fix has been merged. The affected TTCN3 tests pass again. We can close the ticket now.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)