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/gerrit-log@lists.osmocom.org/.
pespin gerrit-no-reply at lists.osmocom.orgpespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-pcu/+/22604 ) Change subject: nacc: Implement Pkt Cell Change Continue retransmission ...................................................................... Patch Set 5: > Patch Set 5: Code-Review+1 > > conceptual question: Does this implicitly mean that any (optional) SI messages we transmitted meanwhile also are ackonwledged? All of those increment the sequence nubmer and now since we wait for an ACK on the last message (Cell Change Continue), we know it all worked out? Just curious. There's no sequence number increment. Actually there's no BSN at all, since those are CTRL messages, not DATA messages, so the way to ACK them is to set the RRBP bit and wait to get a CTRL ACK at N+13 on the Uplink. That's what we do for the last Cell Change Continue, which is the one instructing the MS to go forward and change cell. We are NOT doing the same for the multiple Pkt Neighbor Cell Data, we are currently just sending them and hope they arrive well. If they don't arrive well, the MS may have partial information and then it will be instructed by the network (Cell Change Continue) to jump to the target cell. The MS will then do regular CS/PS attachment through the new cell. That's mostly the same scenario if we somehow fail to resolve the ARFCN+BSIC -> CGI-PS or CGI-PS -> System Information, we'll simply send the Cell Change Continue without previously sending any Pkt Neighbor Cell Data. That's OK according to specs, and it's basically "hey I noticed you want to move to that other cell because you have better signal there, and I failed to get its SI, but anyway continue and good luck with your new cell". In the other case (some Pkt Neigbhor Cell Data, SI being lost), it probably means the signal is already bad (CTRL messages are CS1), so I'd prioritize simply pushing forward quickly to tell the MS to move on. Moreover, requesting an ACK for each Pkt Neighbor Cell Data (several of them are needed to encode the 3 SI infos) would clog the uplink stealing possibilities for other MS to submit more interesting data. See TS 44.060 8.8.3 Cell Change Notification procedure: """ After receiving a PACKET CELL CHANGE NOTIFICATION message from the mobile station the network can behave in different ways as described below: 1) The network responds with a PACKET CELL CHANGE CONTINUE message. If a mobile station as response to a PACKET CELL CHANGE NOTIFICATION message receives a PACKET CELL CHANGE CONTINUE message without receiving any neighbour cell system information, the mobile station shall stop timer T3208, stop timer T3210 if still running, leave CCN mode and continue cell reselection in NC0/NC1 mode. """ -- To view, visit https://gerrit.osmocom.org/c/osmo-pcu/+/22604 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-pcu Gerrit-Branch: master Gerrit-Change-Id: I7cc28922e71699598da0ef6eb90136a47d3c002f Gerrit-Change-Number: 22604 Gerrit-PatchSet: 5 Gerrit-Owner: pespin <pespin at sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge at osmocom.org> Gerrit-Comment-Date: Tue, 02 Feb 2021 12:38:41 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: No Gerrit-MessageType: comment -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210202/e3ba8795/attachment.htm>