Subject: RE: [SIP] SIP Info Method and IS-41 Cellular Signalling Protocol

From: James Yu <[email-masked]>
Date: Mon, 1 May 2000 09:41:52 -0500

James,

Your question can be addressed by sigtran - SS7 transport over IP.  There
are a few adaptation layers to choose including the newly proposed SUA (for
SCCP users such as IS-41).

James Yu

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Friday, April 14, 2000 5:59 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [SIP] SIP Info Method and IS-41 Cellular Signalling Protocol
> 
> 
> I'm working on a design for replacing the IS-41 North 
> American cellular
> signalling protocol with IP protocols. I had a couple of 
> questions about
> how the SIP INFO method, or potentially another SIP method, might
> be used.
> 
> 1) In the introduction to draft-ietf-sip-info-method-03.txt, exchange
> of radio signal strength information is explicitly mentioned as
> an application of the SIP INFO method. The HandoffMeasurementRequest
> and HandoffMeasurementRequest2 messages in IS-41 are sent by 
> the anchor
> Mobile Switching Center (MSC) to a potential serving MSC to 
> obtain information 
> about the signal strength of a Mobile Station (MS) in order 
> to determine
> if the potential serving MSC is a better candidate for handling the
> mobile's call (called "hard handoff" in cellular jargon). 
> They could be 
> replaced with a SIP INFO method. There are three problems:
> 
> 	a) The radio information is always solicited by the anchor MSC,
> 	and from the ID, the SIP INFO method seems like it is 
> 	sent unsolicted. I suppose one could come up with two INFO
> 	methods, one to solicit the radio information and one to
> 	return it, but this seems like a hack somehow.
> 	
> 	b) In the ID, it explicitly states that the INFO method is 
> 	only applicable when there is a call in progress. Problem is,
> 	there isn't a call in progress between the anchor MSC and
> 	the serving MSC, that's why the anchor MSC is soliciting
> 	the radio quality information in the first place.
> 	
> 	c) The INFO method seems like it is meant to be sent between 
> 	SIP UAC's, while the HandoffMeasurementRequest(2) methods
> 	are primarily designed to be sent between network elements.
> 	A SIP replacement would probably be sent between the 
> last hop SIP
> 	proxies acting as Call Agents (CAs) for the call, which replaces
> 	the MSC in an all IP network.
> 
> 2) There are a bunch of IS-41 messages that involve transmitting
> feature or other information between the MS's Home Location
> Register (HLR) and the MS. These are initiated by either the serving
> MSC or the HLR. Examples are InformationDirective, which is used
> by the HLR to provide notifications to an idle MS, and FeatureRequest,
> which sends particular features to a potentially idle MS (features
> being things like messages or playing particular tones). Again, these
> seem like candidates to replace with the SIP INFO message, but 
> the potential lack of any call in progress would prohibit that.
> 
> The alternative I could see would be establishing a session in order
> to then send the information via the INFO method, but that seems like
> overkill. And in the case of HandoffMeasurementRequest(2), the
> message isn't intended for a SIP UAC anyway.
> 
> Maybe SIP is the wrong protocol to consider, since it is dedicated
> to setting up and maintaining sessions, and not to exchanging 
> information
> between network elements or between network elements and terminals?
> 
> Can anybody provide some guidance?
> 
> 		jak
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Giuseppe Ricagni <[email-masked]>
Date: Tue, 02 May 2000 12:38:33 +0200

> SCCP users such as IS-41).

Yes.

You definetly don' t need SIP if you only want to tunnel legacy
signalling
protocols over IP: SIGTRAN does the job much better (providing for
endpoint
redundancy, scalability, through the concept of multiple streams within
an
association, encompassing a very efficient SACKs implementation that
gives its
best in case of retranmission of small chunks of information, just like
signaling messages, and.... really much more).

IMHO, you should tunnel in SIP (over SCTP, maybe) when you really add
something
to the base protocol, e.g by means of the SDP attributes SIP can carry,
that
allow for the negotiation of much richer sessions.

The point is that this is actually the case, at least in many 3G
cellular
scenarios.

A completely new (SIP-based if SIP can provide all the necessary
features)
approach  could be also welcome in many cases.

Giuseppe

----------------------------------------------------------
Giuseppe RICAGNI
System Architecture and Product Planning
Broadband Networks
Italtel
via Reiss Romoli - C10
20019 Castelletto di Settimo Milanese (MILANO)
ITALY

mailto:[email-masked]
----------------------------------------------------------

--
----------------------------------------------------------
Giuseppe RICAGNI
System Architecture and Product Planning
Broadband Networks
Italtel
via Reiss Romoli - C10
20019 Castelletto di Settimo Milanese (MILANO)
ITALY

mailto:[email-masked]
----------------------------------------------------------