User Notification Protocol

Nikolai Leung, QUALCOMM Incorporated nleung@qualcomm.com (703) 346-8351

Notice: QUALCOMM Incorporated grants a free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner’s name any Organizational Partner’s standards publication even though it may include portions of the contribution; and at the Organization Partner’s sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner’s standards publication. QUALCOMM Incorporated is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution.This document has been prepared by QUALCOMM Incorporated to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on QUALCOMM Incorporated. QUALCOMM Incorporated specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of QUALCOMM Incorporated other than provided in the copyright statement above.

History

Presented x31-20051024-016 in October meetings

Comments at October meetings Investigate reducing overhead of

SUBSCRIBE-NOTIFY method Investigate using PUBLISH method

Also specify a solution that does not rely on IMS

General UNP Architecture

Serving Network

Home Network

AT/MS

AN/BS

PDSN

PrepaidServer

Notification Server(NS)

OtherNotificationApplication

HoliningRedirectServer

General UNP Architecture 2

Notification Server (NS) in the home network Simplify security between NS and network

applications that trigger notifications Do not standardize interfaces between

the NS and network applications that trigger notifications Co-locate network applications with NS or

provide secure proprietary interfaces to the NS

Protocol Proposal v2 Not invent a new protocol Use SIP-MESSAGE Method (RFC 3428)

Extension to SIP that allows transfer of Instant Messages.

Prepaid balance/notification is sent to the terminal in a SIP MESSAGE

Avoid overhead of SUBSCRIBE-NOTIFY method

More appropriate than PUBLISH method Establishes soft state in terminal, terminal acts as

server/compositor

SIP-MESSAGE Method

Terminal NS

MESSAGE

200 OK

PrepaidBalance Low

Proxy

MESSAGE

200 OK

UNP over IMS

Serving Network

Home NetworkAT/MS

AN/BS

PDSN

PrepaidServer

Notification Server(NS)

OtherNotificationApplication

HoliningRedirectServer

S-CSCFP-CSCF

P-CSCF can alsoreside in the home

network when he AT/MS is roaming

Leverage IMS for architecture, security, and accounting

NS is an Application Server in the home network that sends the SIP MESSAGE through the IMS network to the terminal

UNP for Non-IMS Network NS acts as combined SIP registrar/AS

Terminal registers current IP address with NS only for IP-reachability

Serving Network

Home Network

AT/MS

AN/BS

PDSN

PrepaidServer

Notification Server(NS)

OtherNotificationApplication

HoliningRedirectServer

UNP Registration for IMS 3rd party registration with NS by SIP registrar

based on User Service Profile in the HSS Registration with NS indicates that the AT/MS

expects notifications and is reachable

PDSN NotificationServer

AT/MS

SIPRegistrar

IMS Register

HSS

Request UserService Profile

IncludesNS address

Event thatcauses IMSregistration

3rd Party Registration for AT/MS

Operator addsNS address toUser Service

Profile

UNP Registration for non-IMS AT/MS registers directly with NS to provide

IP address information AT/MS procedure identical to IMS procedure

PDSN NotificationServer

AT/MS

SIP Register

Provisionedwith FQDN of

NS

IP addressassignment

User Notification Delivery

NotificationServer

AT/MS

P-CSCF S-CSCF

MESSAGEMESSAGE

PrepaidServer

LowPrepaidBalance

200 OK

“SendNotification”

I-CSCF

MESSAGEMESSAGE

200 OK200 OK

200 OK

IMS: NS sends SIP MESSAGE to SIP-URI of terminal

NotificationServer

AT/MS

MESSAGE

PrepaidServer

LowPrepaidBalance

200 OK

“Send Notification”

Non-IMS: NS sends SIP MESSAGE directly to the IP address of the AT/MS

Delayed Delivery over IMS Undelivered messages can be queued until terminal re-

registersNotificationServer

AT/MS

SIPRegistrar

S-CSCF

MESSAGEMESSAGE

PrepaidServer

LowPrepaidBalance

200 OK

“SendNotification”

I-CSCF

MESSAGE

200 OK200 OK

MESSAGE

AT/MS isnot-

registered/

reachable

REGISTER3rd Party Registration

Notification isqueued

Terminal isnow reachable

Not Found

Delayed Delivery over non-IMS Undelivered messages can be queued

until terminal re-registersNotificationServer

AT/MS

MESSAGE

PrepaidServer

LowPrepaidBalance

“Send Notification”

200 OK

MESSAGE

AT/MSis

not-registered

/reachable

REGISTER

Notification isqueued since

no ack

Terminal isnow reachable

Security for UNP over IMS Hop-by-hop security provided by IMS

AT/MS to P-CSCF Authentication: HTTP Digest authentication using

AKA Encapsulation: IPSec

P-CSCF to S-CSCF: relies on IMS inter- and intra-domain security

Security between the NS and S-CSCF: Rely on IMS intra-domain security

Security between the NS and network applications requesting notifications (e.g Prepaid server) is assumed but outside of scope

Security for UNP over IMS2

Tying it together The NS ensures that notification requests

come from a trusted network application E.g., Prepaid balance notification can only be

requested by the prepaid server The S-CSCF inserts P-Asserted-Identity Tag =

“3GPP2 Notification Server” only on SIP MESSAGE from the NS

AT/MS displays messages with “3GPP2 Notification Server” tag as authenticated system message

UNP Security for Non-IMS Establish secure tunnel directly between

NS and Terminal TLS

PSK – Pre-provisioned in the R-UIM GBA – For further study because of concerns

about long-term bootstrapped key in terminal Expect TLS/TCP session to time out between

notifications Re-establish TCP and TLS sessions before sending

notification AKA+IPSec

Can use UDP to avoid need for TCP state Not desirable because NS needs interface to HSS

UNP Interaction with NFCC

IMS: UNP to Leverage IMS solution UNP SIP MESSAGE traverses the same

pinhole established between the AT/MS and P-CSCF for IMS

Non-IMS For further study pending NFCC design Expect NS to open pinhole before

sending SIP MESSAGE

Accounting The operator may not want to charge for non-billable

traffic (e.g. unsolicited notifications) from the NS In IMS the S-CSCF generates detailed billing records for

SIP MESSAGE messages between the AT/MS and NS The AAA can use this to determine how to bill traffic

Non-IMS: After a message exchange, the NS sends a report to the AAA indicating how many bytes are exchanged with the NS

The NS counts how many bytes it exchanges with the AT/MS This count should include any overhead bytes the PDSN would

count AAA adjusts prepaid balance based on this report from the

NS Before cutting off access, PDSN goes back to AAA to see adjusted

balance Rely on same intra-domain security to ensure that

AAA can trust accounting reports from NS NS can trust that notification requests from network applications

will send valid non-billable traffic

Content of SIP MESSAGE

Content-type: Application/vnd.3gpp2.ns

MESSAGE content structure Define simple XML schema Or Define Binary Coded Data

Next Steps Division of work in 3GPP2

MMD develop UNP Protocol since approach is SIP MESSAGE-based

TSG-S WG 4 develop security model for Non-IMS solution

PDS provide input on non-IMS solution PDS provide input on structure of SIP

MESSAGE contents Register vnd.3gpp2.ns MIME type with

IANA