I have always seen that paging coming on Iu interface from CN over RANAP is of sccp class 0 (UDT,LUDT,XUDT).Please help me whether this paging can be sccp connection oriented also. Please clarify the difference between PAGING type1 and PAGING type2 .where we can see these types in RANAP message. asked 05 Apr '14, 23:02  CUFF and LINGS edited 07 Apr '14, 04:53 |
One Answer:
No, it's illegal to send a page message over a connection-oriented SCCP link as per 3GPP TS 25.413 section 9.1.3 (third line defines it as connectionless-only). Aside from not being allowed in the spec, though, why would you ever want an SCCP connection to be established for a page message? Keep in mind here that the page is a single message which isn't responded to, triggering a service request by the UE as a whole other RANAP transaction (which will be connection-oriented at SCCP layer). Since the page request can be sent to many RNCs, the majority of page requests won't trigger anything beyond that one message, so by adding a connection setup/teardown to each of those RNCs for each page procedure you end up making the already signaling-intensive procedure much less efficient. Edit: For your last question about paging type 1 and type 2, these concepts don't exist in RANAP and if you understand what those types are, and why the RNC is being paged to begin with, you should understand why. The difference between those types (within the radio network) is that one is toward an established RRC connection whereas the other is over the global paging channel. To decide type 1 versus type 2, you would need to know if the UE has an active RRC connection. If a core network is sending a page request, then it does not know which RNC (if any) is serving the UE and thus definitely does not know whether an RRC connection exists to specify it one way over the other. The only thing the Core network can do here is include the non-searching indication attribute over RANAP, to say whether or not to attempt to coordinate mobility state between two core networks (eg: between a CS and PS core network) based on the "Common ID" value known to the RNC (the IMSI). The RNC, if not explicitely asked not to by the core network, can make a decision (called the "UTRAN paging co-ordination function" in the spec) to determine whether the page should be handled as type 1 or type 2. Simply put, the only thing that a core network can do is say "If you have a matching Common ID, send the page over the existing RRC channel that it maps to for this user that I'm requesting a page for". It is still an "IF", though, and the ultimate decision is really up to the RNC there to control paging in the UTRAN. answered 07 Apr '14, 18:08  Quadratic edited 07 Apr '14, 18:14 showing 5 of 8 show 3 more comments |
Thanks a lot for the detailed explanation. I was expecting same thing and its good to know if some one authenticate you. I have one more question related to SCTP-M3UA-SCCP signalling.
1.when an SCTP association is formed with a four way handshake procedure INIT INIT-ACK COOKIE ECHO COOKIE ACK
2.After that M3UA signalling is started. ASUP ASUP ACK DAUD DAVA
3.Then SCCPMG comes into picture SST SSA
I need to know that for M3UA and SCCP it is necessary that If SCTP link is broken and reestablished than M3UA and SCCP will also reestablish or how the M3UA and SCCP link reestablishment works ?
I have a trace please share the path so that I can upload it.
Thanks
@CUFF and LINGS
Your "answer" has been converted to a comment as that's how this site works. Please read the FAQ for more information.
An SCTP four-way handshake is established when you're initially configuring an Iu control interface. That association should stay up 'forever', or until something breaks (eg: maintenance activities). Usually, you'll have more than one SCTP association as well but that depends on implementation (eg: some vendors might require an association-level outage for types of planned work, in which case establishing two gives more flexibility). For SCTP paths, depends again on implemtation but typically you'd have at least two IPs on both sides, so at least four paths effectively. And that's per-association.
After association, yes you'd need to establish MTP3-level connectivity (M3UA in this case) over that association, then the RANAP subsystem's availability is confirmed via SCCP-level SST/SSA exchange. From your wording I'm not sure if you're asking a question there. :)
For the failiure handling at these layers, SCCP is agnostic to SCTP path failures (at least directly). For M3UA, communication between those layers is governed by RFC 2960 section 10.1 (M3UA toward SCTP) and 10.2 (SCTP toward M3UA, eg: when SCTP failures occur like what you're asking about), where M3UA is the "ULP" or "Upper-Layer Protocol". In short, yes M3UA can learn from SCTP that an ASP/IPSP or AS/SG are unavailable from SCTP if paths or associations fail. For this reason it's usually not recommended to implement M3UA-level heartbeats when you are running it over SCTP (technically, you're allowed to not run it over SCTP but since SCTP and M3UA were created hand-in-glove in the Sigtran project I'd call it at least very unusual to not run it over SCTP).
For the packet capture, you can upload it here and post the URL that it gives you for it: https://appliance.cloudshark.org/upload/
I have uploaded the trace.Thanks for the reply and reference of 2960. I still have a doubt that If Lower layer (SCTP) the Server sends and ABORT and connection is tear down ungracefully than in that case M3UA ASP will also fail and when new SCTP connection is established than new M3UA association will happen .As you said that SCCP is agnostic to SCTP.than we only need to talk about M3UA.
From the trace can we find a common IE that can SCTP with M3UA ?
You uploaded the trace but could you post the URL here?
For your question, it's answered in the spec I'd cited (section 10.2, SCTP-to-ULP primatives). If an SCTP Abort chunk is received, then SCTP will pass the related primative to the M3UA layer to tell it that the transport is down. It's not in Wireshark, and it's not in a trace file, it's in the internal logic of the system that receives the SCTP Abort message for what it recognizes maps to an M3UA Association.
Sorry for the URl !!
https://www.cloudshark.org/captures/839e9b681d59
Thanks.
There's no abort in that trace file, so I'm kind of confused now on what your question is. I think I answered it above (SCTP talks to M3UA within the local system receiving the Abort with those primatives), but can you clarify if you still have a question? The trace file is of a normal-looking Iu establishment (based on SSN 142), though nothing after it, and no abort.
Yes my Doubt is clear now ..I have read 2960 as per your reference thanks for the help..