The RAN’s part is finished the moment the UE lands on the 2G cell. What you call data handover is done by the core after that: the UE sends a Routing Area Update on 2G, the SGSN pulls the MM and PDP contexts from the MME (Context Request/Response over S3 for an S4-SGSN, over Gn for a Gn-SGSN), then re-establishes the PDP contexts towards the PGW (Update PDP Context over Gn, or Modify Bearer via the SGW for S4). If any step in that chain fails, the UE stays attached on 2G with no PDP context, which is exactly what you see. So the check list is core-side, in this order:
Post the RAU Accept and the Context Response for one failed IMSI and the failing step is visible in two lines.
Good, that clears the core: Update PDP Context accepted, RAU through, contexts kept. Your capture also shows where it dies. FLOW-CONTROL-MS from the BSS means the PCU opened a downlink TBF for this MS and the SGSN started sending; it happens twice, then the BSS sends RADIO-STATUS. RADIO-STATUS is the BSS telling the SGSN it cannot serve that MS on the radio any more, and its Radio Cause IE is the answer to your question. Expand it. The three values that matter: radio contact lost with MS or radio link quality insufficient means the DL TBF assignment was never acknowledged on the PDCH, so look at PCU resources and coverage of the target cell; cell reselection ordered or prepare means the MS is leaving the cell right after landing, and the usual case is reselection straight back to E-UTRAN because the GERAN cell’s SI2quater E-UTRAN priority and thresholds contradict the LTE-side cell change order threshold, so the UE ping-pongs before any data moves.
Two more things from the same trace: the TLLI in RADIO-STATUS and FLOW-CONTROL-MS against the TLLI the SGSN used in its DL-UNITDATA after the RAU (a P-TMSI reallocation changes it), and whether the SGSN sent any LLC user data on SAPI 3, 5, 9 or 11 before the RADIO-STATUS. Post the RADIO-STATUS cause and that settles which of the three it is.
That closes the TLLI question too: 0x90b80464 is the foreign TLLI built from the mapped P-TMSI (top bits 10), the SGSN reallocates and switches to the local TLLI 0xd2d80443 (top bits 11), and every message after the RAU Accept uses the new one consistently. Control plane is clean end to end: RAU, two network-initiated Modify PDP Context rounds both accepted, Update PDP Context accepted.
What this capture also shows is that no user data was ever attempted on either side. There is no LLC frame on a user SAPI (3, 5, 9 or 11) in UL-UNITDATA or DL-UNITDATA, and no GTP-U G-PDU on Gn-U. So the next filter is gtp.message == 0xff || llcgprs.sapi != 1 on the same trace, and the answer is one of three:
Also open the negotiated QoS IE in the second Modify PDP Context Request and read the maximum bit rate UL and DL; a mapping that lands on 0 kbit/s gives a live PDP context that carries nothing. And confirm the test itself was generating uplink (a running ping or download) at the moment of the cell change, otherwise there is nothing for the trace to show.
Yes, during the test continous ping was running to generate uplink. When I filtered with gtp.message == 0xff || llcgprs.sapi !=1 in the same trace, it didn’t showed anything.
Also please note 2G data was working with we detach and reattach to 2G. The issue is happening only during handover from 4G-2G.
That is the finding, then. The MS never touched a user SAPI: no SN-UNITDATA, not even an LLC XID on SAPI 3, 5, 9 or 11, with a ping running. The BSS cannot filter by SAPI, so the modem itself did not consider any PDP context usable for data after the inter-system change, while the same modem sends data after a native 2G attach. The difference between the two cases is where the modem gets its A/Gb parameters: on a 2G attach they come in Activate PDP Context Accept; after 4G to 2G they come in the network-initiated Modify PDP Context Request, and the MS may not transmit on a PDP context until it holds a valid LLC SAPI and radio priority for it.
So open both Modify PDP Context Requests and post the values of TI, LLC SAPI, Radio priority, Negotiated QoS (traffic class, maximum bit rate UL and DL) and Packet Flow Identifier, next to the same IEs from the Activate PDP Context Accept of your working 2G-attach trace. An LLC SAPI of 0, meaning not assigned, or a maximum bit rate of 0 kbit/s in the Modify is accepted by most MSs and then silently never used, which is exactly your picture. If those IEs are correct, one more question before anyone touches the RAN: how long did the MS stay on the cell after the second Modify PDP Context Accept? With a 1 s ping you need at least ten seconds of dwell to prove absence.
Then the SM side is valid: SAPI 11, radio priority 4, and the uplink maximum bit rate is not zero (if that column is the raw octet, 151 decodes to 2048 kbit/s and 141 to 1408 kbit/s per 24.008 10.5.6.5). With more than ten seconds of dwell and a running ping, the MS holds everything it needs and still never sends a single LLC frame on SAPI 11. There is also no BSSGP SUSPEND after the RAU in your first capture, so a CS location update suspending GPRS is out.
That leaves one fork, and Gb cannot resolve it because it only shows frames the PCU has already received. You need the Um/Abis side for that TLLI after the second Modify PDP Context Accept: did the MS send a Packet Channel Request (or RACH one-phase access) at all, and did the PCU answer with an Immediate Assignment / Packet Uplink Assignment?
Post the Abis or PCU log for that TLLI in the ten seconds after the last Modify Accept and the fork is decided.
The same MS were able to attach 2G and do the browsing when we detach and attach or when we directly attach to 2G. However as you mentioned during inter-system change, not sure why MS is not putting ping on air. And I can confirm that ping ran on phone itself. Regarding RAN BSC or PDCH problem, since 2G browsing was working when directly connects to 2G (issue only during HO), can this be still RAN issue?
Not the 2G RAN. The BSS only relays what the MS puts in an uplink TBF, and the MS put nothing on SAPI 11. The one RAN way to get this picture is a PCU refusing uplink TBF requests, and that is visible on Um or Abis, not on Gb.
Where the two cases differ:
Direct 2G attach: the MS gets LLC SAPI, radio priority and TI in Activate PDP Context Accept from the SGSN. Works.
4G to 2G change: the MS gets them from the MME in LTE (Activate Default EPS Bearer Context Request), the SGSN inherits them in the Context Response, and the SGSN only corrects them if it decides to send Modify PDP Context. Fails.
A PDP context that lands on 2G without a valid LLC SAPI is one the MS may not transmit on until the network modifies it. You have two Modify PDP Context Requests but one Update PDP Context on Gn, so one context may have been modified twice and a second one never touched.
What to post, in order:
If the internet context shows a valid SAPI and radio priority in 1, 2 and 3, the network is clean and it is the phone.
I will also try to get Abis interface trace. Could you please tell me command to check Abis IP for 2G cell from Ericsson BSC
Cell to TG: RXTCP:MOTY=RXOTG,CELL=; TG data, including the Packet Abis parameters: RXMOP:MO=RXOTG-; Abis path of that TG: RXAPP:MO=RXOTG-; BSC side IP of the Abis over IP link (the PGW IP gateways): RRGWP;
The RBS side address is not printed per cell in the BSC; read it from the STN that carries the site (SIU, TCU or Baseband transport configuration). For the trace, mirror the router or switch port facing that STN and filter on its IP; that gives you the complete Abis for the site. Then look for the Packet Channel Requests and uplink assignments of that TLLI in the ten seconds after the last Modify PDP Context Accept.
Our 2G is connected to Baseband. So should I need to host IP of MO(Router=ABIS,InterfaceIPv4=1,AddressIPv4=1 ) in wireshark to get Abis trace?
Yes. On a Baseband running GSM, Router=ABIS, InterfaceIPv4=1, AddressIPv4=1 is the node’s Abis endpoint; the value of its address attribute is the IP you filter on. Mirror the transport port of the Baseband (or the router port facing it) and use host in Wireshark; the other end of every Abis packet will be one of the PGW addresses from RRGWP; on the BSC.
One thing to know before you rely on that capture: Ericsson Packet Abis over IP is not RSL and OML in the clear. It is Ericsson’s own L2TP-based framing, the same dialect the SIU speaks, and stock Wireshark decodes it only down to the L2TP layer; the Packet Abis frames inside, including the PCU messages you are after, are proprietary and stay opaque. So the capture proves transport and timing, not the TBF question.
For “did the MS request an uplink TBF after the last Modify PDP Context Accept”, use one of these instead: a BSC-side Cell Traffic Recording (CTR) on that cell for the test window, which logs channel requests and assignments per cell without decoding Abis; or, more directly, the phone itself with an Um log (QXDM or the equivalent for its chipset), which shows every Packet Channel Request the MS sends and every assignment it receives. The second one answers the RAN-versus-phone question in one look.
Okay, before I explore that, I would like to know if there is any parameter in LTE Ericsson BBU we can select PS Handover enabled. I remember there is one parameter where we can select CS only or CS and PS
Check the MOM of your release before.
What I can say: on Ericsson LTE, data mobility to GERAN is delivered as Session Continuity to GERAN, which is a cell change order with NACC, not a PS handover; PS handover to GERAN is not something I have seen in the Ericsson eNB feature set, and your trace confirms you are on the CCO path anyway, since the MS did a RAU with a foreign TLLI on arrival. A PS handover would have shown Forward Relocation on S3/Gn and no RAU.
The attributes to look at are on GeranFreqGroupRelation under the EUtranCell: the connected-mode priority that governs session continuity, and csFallbackPrio which governs CSFB only. That pair is probably the “CS only versus CS and PS” you remember; they are two separate priorities, not a mode switch. The quickest way to see what is actually in use is the LTE Uu trace: open the MobilityFromEUTRACommand and read whether it carries cellChangeOrder or handover.
Either way it does not change the finding. The control plane already completes correctly after the cell change; switching mechanism would not make the MS transmit on SAPI 11.
Okay,let me see, so does it mean during LTE to 2G handover, PS will not be handover? Only cell reselection happen?
