This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

RANAP : non searching indication paging failure

0

Hello,

I am currently facing an issue where the Core Network is sending two additional parameters while paging into m network. I dont know why but paging fails (the internal logs say that the UE is using type 2 paging). I suspect that this parameter is indirectly involved in this. Please suggest?

asked 30 Mar '14, 22:45

Balrog2486's gravatar image

Balrog2486
11113
accept rate: 0%

edited 06 Apr '14, 00:14

Can any body please suggest if paging is affected by this parameter or not?

(01 Apr '14, 01:20) Balrog2486

One Answer:

1

Can you post the RANAP packet capture to something like cloudshark (https://appliance.cloudshark.org/upload/ ) and post the link here?

What additional parameters are you seeing, specifically? When the page procedure fails, is there any error indication over the wire? Does the UE see the page request and respond to it? As for "type", at least in spec there's no such IE in a RANAP Page request. Also what vendor RNC is this that is giving you that log message?

Edit: Just reread this. The question is still a bit confusing but I think you're asking about one parameter specifically (non-searching indication), and its affect on paging, correct? If that is your question, then yes it definitely does affect paging logic.

Refer to the RANAP spec (25.413) for more details, but basically if 'non searching indication' is included and "search" is not set, it means the RNC shouldn't bother mapping the RRC connections to the Iu connections for the UE, so for the page procedure it should use the paging broadcast channel for the LAC/RAC rather than the existing RRC channel toward the given UE.

answered 01 Apr '14, 15:11

Quadratic's gravatar image

Quadratic
1.9k6928
accept rate: 13%

edited 02 Apr '14, 16:07

Thanks. That parameter has to to with paging coordination for the UE.

As a practical example, let's say you have a UE which has registered on both a GPRS Core (SGSN) and circuit-switch Core (MSC). If the RNC receives a page request for the UE from an SGSN, but the UE already has an active RRC connection to signal to the MSC, what is the most efficient thing for the RNC to do?

If there's no coordination between the two core networks by the RNC, it would have to page the whole routing area of NodeBs because the UE is in PMM-Idle mobility state and thus has no known cell to the SGSN, even though the RNC knows the serving cell because the UE has an active RRC connection for the MSC signaling.

To add efficiency here, the concept of a "Common ID" is used between core networks, which is basically just the IMSI (I have never seen it not be the IMSI, and even the 3GPP specs put IMSI in brackets for defining the Permanent NAS identifier for the UE). There's a dedicated exchange for sending the RNC this "Common ID".

Because the RNC has this permanent identifier, if requested as part of the page procedure by an SGSN or MSC, with "search" indicated in the "non-searching indication" IE, that tells the RNC that it can attempt to locate the UE based on whether or not it has an RRC connection at the time of the page. If it doesn't then it has no choice but to page the whole LA/RA, but if it does then it can identify the cell and prevent a redundant page procedure.

In your trace, an SGSN at 0-51-46 is paging two RNCs at DPC 0-52-84 and 0-51-70 for IMSI 286015215017435 in packets 491 and 493 (because both RNCs serve RA 1, which would be the last-known RA for the UE). In both cases, the SGSN is asking the RNCs to perform that search procedure, and associate any RRC connection for the same "Common ID" with this UE for the purpose of paging optimization.

Without NBAP or Uu control in the trace it's impossible to say why there was no response to the page requests, but I think you're looking at a red herring with that Common Id and Non-Searching Indication IE. Again, those are defined in the spec I'd sited before for RANAP signaling and they look normal to me.

(02 Apr '14, 16:00) Quadratic

Ok, I think a few mobility management concepts are being confused here:

"PMM-Idle" is a state that a UE can be in toward an SGSN. This means basically that the UE is registered (and expected to send periodic routing area updates), but does not have a RAB in the PS Core. This is in contrast to "PMM-Connected" state where the SGSN knows the serving RNC of the UE (and consequently the UE has an RRC connection open).

The SGSN in your trace does not believe that the UE is "PMM-Connected", in the sense that it knows there is no RAB and it does not know the serving RNC (if there even is a serving RNC for the UE). It does, however, believe that the UE has a PDP Context.

Whether or not the UE has an "active" PDP Context is separate from whether or not it is in idle mode toward the SGSN. "Idle" refers to the UE's "GPRS Mobility Management" or "GMM" state (GPRS registration state toward the SGSN). For the main three mobile core types (CS, GPRS, EPS), you have the same logical divisions (MM/SM, GMM/GSM and EMM/ESM respectively).

So, for your scenario the SGSN's behaviour here is perfectly normal. After the Iu release (with the UE in PMM-Idle mode), the UE may still have a PDP Context and thus, from the perspective of an upstream GGSN it still has an IP address in a packet data network. If something in that network is trying to reach the UE (eg: a pushed email application, or an incoming SIP-based voice call), the SGSN will need to reestablish contact with the UE. Since the SGSN does not know the serving RNC when the UE is in PMM-Idle mode, it must initiate the page procedure.

That procedure should trigger the UE to send a Service Request message to the SGSN, after the RNC forwards the page and the UE receives it, either over an established RRC channel (because that non-search indication IE is set to search) or over the global paging channel by a nearby NodeB, which the UE should be listening for.

Does the RNC forward the page request to the NodeB's in RA 1 (in your example)? Does the UE get that page request? Does it send the service request? These are the questions you need to answer to solve this one.

(03 Apr '14, 15:09) Quadratic

One other thing - The difference between type 1 and type 2 page procedures is transparent to the SGSN, and at a RANAP level the distinction is not drawn. The SGSN does not know whether an RRC connection exists or not for this UE toward another CN.

From your description, are you saying that the page is being sent on an old/expired RRC channel rather than the global paging channel toward the UE, when the UE is idle and without an active RRC connection? If so, that would pretty much have to be an RNC problem since "UTRAN paging co-ordination" is the responsibility of the RNC. The SGSN can ask the RNC to check whether there's a matching Common ID or not for any existing RRC connection (and your SGSN is asking your RNCs to do that, based on the non-searching indication IE), but the RNC is the one to say "yes, there's an RRC connection for that UE, I'll send on the RRC channel" or "no, there's no RRC connection with that Common ID, I'll send on the global paging channel".

(03 Apr '14, 15:26) Quadratic

Hello,

Can you tell me if this analysis is correct from the Node B logs...

IMSI : 286015620628136

A PS Call is established initially mmgmm_nas_cs__establish_req_hdlr: started new zsession.

UE State is Read as IDLE:

RRC <- MMGMM: RANAP_PAGING [IDLE] [PS] RRC <- MMGMM: RANAP_PAGING [IDLE] [PS]

Signaling Connection Request for the UE is added :

handle_signalling_connection_request_add_to_sm_and_allow: Ueid=7120 maps to imsi=286015620628136 SC -> RRC: RRC_SC_SIGNALLING_CONNECTION_RESPONSE [user 7120]

URNTI is calculated for the UE in Idle mode (which is incorrect as the UE is read as IDLE and requires a normal paging message) Calculated U-RNTI as B5333326 using CellID 0000006 and SRNC ID B53

This suggests that the UE is connected to the SGSN (through Active PDP or active RAB). So during paging the SGSN sends Search Indication to INC but that parameter is not actually forwarded to the FAP for unknown reasons and the UE reaches an invalid state.

(04 Apr '14, 11:18) Balrog2486

No, the UE may have a PDP context but it does not have an active RAB to the SGSN. The SGSN is sending the page in order to have the UE initiate a "Service Request" to establish a new RAB.

The UE is where you need to really zoom in here. Does the UE receive the page request on an RRC channel or the global paging channel (looks like it's sent on an RRC connection)? If received on an RRC connection, does that RRC connection exist from the perspective of the UE?

The logs show the RRC connection was established from the NodeB's perspective and that the page was sent over it. If that's true, either the RRC channel existed (in which case, the UE is wrong to not receive the page and initiate a service request) or the channel did not exist (in which case the RNC incorrectly mapped the page request's Common ID to that of an existing RRC connection, indicating a bug or logic error on the RNC).

If this is happening in a small percentage of cases, it's possibly a timing issue caused by coverage, if the UE's RRC connection is up but the physical air interface is unable to communicate the page. That might explain the unstable state the UE is getting stuck in (the SGSN would also likely have the UE in an unstable GMM state due to this), but that would make this scenario relatively normal and probably not preventable. There will always be a small percentage of UEs in an unstable mobility management state due to these kinds of scenarios.

(04 Apr '14, 14:51) Quadratic

Thank you for all the help.

Maybe that is the reason why I can see RAB Release Request with Cause as User Inactivity and No Remaining RAB messages.

Also I was able to see the following in the RANAP trace which actually proves that the UE is in unstable state:

radioNetwork: radio-connection-with-UE-Lost (46)

I think this confirms that the UE lost connection at the time of Paging.

Thanks again but I think this will ocnfirm the problem.

(05 Apr '14, 12:33) Balrog2486
showing 5 of 6 show 1 more comments