Not quite. Three different things exist, and only one is a handover:
Cell reselection: idle mode, UE decides alone from priorities and thresholds, no network command.
Cell change order with NACC: connected mode, network-commanded (MobilityFromEUTRACommand with cellChangeOrder). The UE leaves LTE, camps on the target 2G cell, does a RAU; the SGSN pulls the contexts from the MME and the PDP contexts survive. The session continues, but nothing is prepared in the target before the UE moves, so there is a gap of roughly one to three seconds. This is what your trace shows and it is what Ericsson LTE uses for data. Release with redirection to GERAN ends in the same RAU path.
PS handover (TS 43.129): the target BSS allocates the PS resources before the UE moves, the MME does Forward Relocation to the SGSN, the UE arrives with a TBF already assigned, gap in the hundreds of milliseconds. It needs support on eNB, MME, SGSN and BSC/PCU together, and it is not what your network is doing.
So PS is not lost in your case: the RAU was accepted with the contexts kept and the PDP context was updated to the PGW. The problem starts after that point, which is why the mechanism choice is not the fix.
2G side. The eNB’s part ends with the cell change order, and yours worked: the MS landed on the intended cell and did its RAU there. Everything after that is BSC, PCU and RBS: GPRS/EGPRS activation on the cell, PDCH availability, uplink TBF assignment. Nothing on the eNB can stop an MS that is already on 2G from sending.
But hold the parameter hunt until you have the Um or CTR evidence. If the MS never sends a Packet Channel Request after the Modify Accept, no 2G parameter will fix it; if it sends and the PCU does not assign, then the cell’s PDCH and TBF settings are the place, and you will know which one from what the PCU answered.
Not from an ENM screen. CTR is started and stopped on the BSC itself by MML, and the recording files land on the BSC’s APG, so ENM only gives you the terminal session to the BSC and a way to fetch the files; you then need a CTR parser to read them. Take the exact initiate and end commands from your BSC’s command description rather than from me.
One caution before you spend the effort: CTR is a Layer 3 recording of the circuit-switched side (channel requests, immediate assignments, assignments, handovers, releases). Check the CTR event list in your release for GPRS one-phase access and PCU-originated immediate assignments; if those are not in it, CTR will not show the uplink TBF attempts you need, and the phone-side Um log remains the direct evidence.
Good. In the Context Response, look at the PDP Context IEs, one per bearer, and read for each: NSAPI, TI, LLC SAPI, Radio Priority, QoS negotiated (traffic class and MBR UL/DL), PDP type and the GGSN control/user addresses. Post those fields, plus how many PDP Context IEs there are. Then set them next to the two Modify PDP Context Requests: same TI or two different ones, and whether the internet context arrived with a real SAPI or with “not assigned”. That is the comparison that decides the network side.
That closes the SM side of the network. One PDP context, NSAPI 5, arrived from the MME already complete: SAPI 11, radio priority 4, packet flow ID 8, active, and the SGSN handed the same values to the MS in both Modify PDP Context Requests (same TI, same context). So the MS holds a consistent, valid parameter set; the network did not deprive it of anything, and the one Update PDP Context matches the one context.
Two things remain, and only one is network-side. The network one is the packet flow ID: 8 is a user-assigned PFI, not one of the predefined ones (0 best effort, 1 SMS, 3 signalling), so if PFC feature mode is enabled in the cell’s SI13 the PCU expects a BSS packet flow context for PFI 8, and your Gb capture shows no CREATE-BSS-PFC from the SGSN after the RAU. Check SI13 on that cell and, from your working direct-attach case, which PFI that PDP context got. If PFC is on and there is no PFC for 8, the PCU’s handling of the MS’s TBF request with PFI 8 is the RAN-side suspect. If PFC is off in the cell, the PFI is ignored and the network is clean end to end, which leaves the phone: Um log or a second handset model.
The GPRS cell data printout is RLGSP:CELL=; (RLGSP:CELL=ALL; for the whole BSC); SI13 is built from the parameters in that printout, so the PFC support setting for the cell should be there. Look for the packet-flow-context entry in that printout for your release. If it is not a per-cell parameter in your release, it is a BSC-level GPRS setting or a feature key, and the command description for RLGSP will point to the right one.
I read in Ericsson CPI that, R99 QoS needs to activate then the the Information Element PFC_FEATURE_MODE will be set to one in SI13 indicating that the cell supports the new R99 QoS. I will try doing this.
Don’t activate it yet; read the current value first. Everything depends on what SI13 says today:
PFC_FEATURE_MODE = 0 now: the PCU ignores the PFI, the packet flow context is not involved, and the RAN suspect I raised is gone. Activating R99 QoS would then add a new dependency (the SGSN must create a BSS PFC for PFI 8 before the PCU serves it), not remove one. That is not a fix for this case.
PFC_FEATURE_MODE = 1 now: then the missing CREATE-BSS-PFC in your Gb capture matters, and the question moves to the SGSN side, whether BSS PFC procedures are enabled there.
You can read the current value from any phone Um log (SI13 on the target cell) or from the GPRS cell printout. Activation is a cell-wide behaviour change for every MS on that cell, so it belongs in a change window with a rollback, and only after the value tells you it is on the path.
Then the packet flow context is out and the network side is clean end to end: the UE got a complete A/Gb parameter set from the MME, the SGSN inherited and re-sent the same values, the PDP context was updated to the PGW, and the PCU has no PFC dependency. Nothing the core or the BSC did differs between your direct-attach case and the cell-change case.
That leaves the phone as the first suspect, because the PCU cannot even tell how the MS arrived; it sees a local TLLI and a Packet Channel Request in both cases, and in the direct-attach case it assigned TBFs fine. So the next step is the cheapest one: run the same test with a different handset model. If the second phone pushes data after the cell change, it is a UE implementation issue and the fix is a firmware update or a handset exclusion, not a network parameter. If the second phone fails the same way, then get a Um log from one of them and we look at what the PCU answers to the Packet Channel Request.
One check you can do in the trace you already have while you arrange that: the MS Radio Access Capability IE inside the SGSN’s DL-UNITDATA after the RAU. It should be a full capability set matching the phone, not empty or truncated; the PCU builds its assignments from it.
Right layer, wrong message. The MS Radio Access Capability is not a GMM message, it is an IE in the BSSGP header of the DL-UNITDATA PDU that carries those GMM messages. In Wireshark, take the frame with the RAU Accept (and the one with the first Modify PDP Context Request), expand the BSSGP layer above GPRS-LLC, and look for the MS Radio Access Capability IE: it should list the access technologies, multislot class and EGPRS capability of the phone. Compare it with the one the phone sent itself in the RAU Request (GMM, mandatory IE there). If they match and are complete, the PCU had correct capability data and that check is closed too.
That is expected. The Protocol column only shows the top layer of each frame and the PDU type column is the NS layer; BSSGP is still inside every one of those frames. Click the frame with the RAU Accept, and in the packet details pane (the middle pane) expand the tree in this order: GPRS Network Service, then Base Station Subsystem GPRS Protocol, and inside it the DL-UNITDATA PDU. The MS Radio Access Capability IE is listed there among the DL-UNITDATA IEs, next to IMSI and DRX Parameters. To pull only those frames out of the capture, use the display filter bssgp.pdu_type == 0x00 (DL-UNITDATA). Then do the same for the RAU Request frame: UL-UNITDATA, expand the GMM message, and compare its MS Radio Access Capability with the one the SGSN sent down.
Separately, that capture is worth a look of its own once this is done: two Attach Rejects after Identity Responses before the third attach is accepted. Read their reject cause; that is a different problem, but not one to leave lying around.
