Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x
Top   in Index   Prev   Next

TR 23.875
Support of Push service

V5.1.0 (Wzip)  2002/04  70 p.
Rapporteur:
Mr. Uda, Nobuyuki
NTT COMWARE Corporation

full Table of Contents for  TR 23.875  Word version:  5.1.0

1Scope  p. 7
2References  p. 7
3Definitions, symbols and abbreviations  p. 8
3.1Definitions  p. 8
3.2Symbols  p. 9
3.3Abbreviations  p. 9
4Introduction  p. 9
5Requirements  p. 9
6General Description  p. 10
6.1Service Environment and Scenario  p. 10
6.1.1 Dedicated Connection Approach  p. 10
6.1.2Connectionless Approach  p. 11
6.2Addressing  p. 12
6.3Dedicated Connection Establishment  p. 13
6.4Push Content Delivery  p. 13
6.4.1Reliable Delivery  p. 13
6.4.1.1Store and Forward  p. 14
6.4.1.2Presence Service  p. 14
6.5Multiple Services  p. 16
6.6Security and Charging  p. 17
6.7User Terminal  p. 17
6.8Roaming Support  p. 17
7Architecture for GPRS  p. 18
7.1Introduction  p. 18
7.2Network requested PDP Context activation with User-ID  p. 18
7.2.1Functional Architecture for Push Services  p. 18
7.2.1.1Application Server (AS)  p. 19
7.2.1.2Address Resolver (AR)  p. 19
7.2.1.3Proxy AS (Proxy Application Server)  p. 19
7.2.1.4Notification Agent (NA)  p. 20
7.2.1.5User Equipments (UE)  p. 20
7.2.1.6GPRS network  p. 20
7.2.2PDP Context Activation with User-ID  p. 20
7.2.2.1Information Flow Example 1 : Dedicated Connection Approach  p. 20
7.2.2.2Information Flow Example 2: Connectionless Approach  p. 22
7.2.2.3Selection of GGSNs in network requested PDP context activation process  p. 22
7.2.2.4Roaming Support  p. 23
7.2.2.5How to protect HLR from signalling overload  p. 23
7.2.3PDP Context Deactivation requested by the UE  p. 23
7.2.4PDP Context Deactivation requested by GPRS network  p. 23
7.2.4.1The UE Goes Out of Coverage.  p. 24
7.2.4.2GGSN initiated PDP context deactivation  p. 24
7.2.5Sharing User activated PDP context with Push Services  p. 25
7.2.6Presence Service  p. 25
7.2.7Proposed Protocol Architecture  p. 27
7.2.7.1Notification Protocol  p. 27
7.2.7.2Update Protocol  p. 29
7.2.8Impact to 3G specification  p. 29
7.3PDP context activation triggered by DNS query  p. 30
7.3.1Definitions  p. 30
7.3.2Assumptions  p. 30
7.3.3Requirements  p. 30
7.3.4General Description  p. 31
7.3.5Proposed behaviours for DNS queries  p. 31
7.3.5.1Lifetime of the PDP context  p. 32
7.3.5.2Choice of Tctxt  p. 32
7.3.6Proposed behaviours for IP data delivery  p. 33
7.3.7Example Scenario  p. 33
7.3.8Alternative PDNS Implementation  p. 34
7.3.9Alternative GGSN Implementation  p. 34
7.3.10GGSN with embedded PDNS  p. 36
7.3.11Avoiding an Application Server Timeout  p. 36
7.3.12Protocol Architecture  p. 37
7.3.13Security  p. 37
7.3.14Roaming Support  p. 37
7.3.15Error Responses  p. 37
7.3.16Impact to 3G specification  p. 37
7.4SMS Push Service  p. 38
7.4.1Assumptions  p. 38
7.4.2Basic Service Scenarios  p. 38
7.4.2.1Short Message Push  p. 38
7.4.2.2Push Notification with User Connect Scenario  p. 39
7.4.2.3Push Broadcast Scenario  p. 39
7.4.3Addressing  p. 40
7.4.4Subscription, Security, and Charging  p. 40
7.4.5Roaming  p. 40
7.4.6Delivery Reliability  p. 40
7.4.7Protocol Architecture  p. 41
7.5Push solution with dynamic address using always on and SMS  p. 42
7.5.1Architecture  p. 42
7.5.2Push proxy  p. 43
7.5.3PUSH initiator  p. 43
7.5.4Push services subscription  p. 43
7.5.5Addressing: Push service using dynamic address  p. 44
7.5.6Presence description  p. 44
7.5.7Delivery of the push message  p. 45
7.5.8Reliability of the delivery of the push message  p. 46
7.5.9Store and forward function:  p. 47
7.5.10Multiple services  p. 47
7.5.11Security  p. 47
7.5.11aCharging  p. 48
7.5.12User terminal  p. 48
7.5.13Roaming Support  p. 48
7.5.14IP address management  p. 49
7.6SIP based Push Service  p. 49
7.6.1IM Subsystem Scenario  p. 50
7.6.2No IM Subsystem Scenario  p. 50
7.6.3Roaming  p. 51
7.6.3.1IM Roaming  p. 51
7.6.3.2Roaming with SIP Proxy in Home Network  p. 51
7.6.4Protocol Architecture  p. 52
7.6.5Addressing  p. 53
7.6.5.1SIP Identity  p. 53
7.6.5.2IP Address  p. 53
7.6.6Subscription, Security, and Charging  p. 54
7.6.7Delivery Reliability  p. 54
7.6.8Connectionless Push  p. 54
7.6.9Quality of Service  p. 54
7.7Push Proxy Based Architecture Using HTTP as Delivery Protocol  p. 54
7.7.1Architecture  p. 54
7.7.2Push Proxy  p. 55
7.7.3Addressing  p. 56
7.7.4Push Delivery Mechanism  p. 56
7.7.5UE Capability Profile  p. 57
7.7.6Roaming Considerations  p. 57
7.7.7Delivery Reliability  p. 57
7.7.8Protocol Architecture  p. 58
7.7.9Security Considerations  p. 58
8 Conclusion and Recommendations  p. 58
AComparison of the Push Techniques comparison  p. 60
BA study on how NRCA and "always on" fulfil PUSH service requirements  p. 61
B.1Introduction  p. 61
B.2Description of the procedures:  p. 61
B.2.1NRCA  p. 61
B.2.2Always on  p. 62
B.3Scalability, or supporting burst of push messages during busy hour.  p. 63
B.3.1NRCA  p. 63
B.3.2Always-on  p. 63
B.3.3Conclusion  p. 63
B.4Delays  p. 63
B.4.1Always-on:  p. 63
B.4.2NRCA:  p. 64
B.4.3Conclusion  p. 64
B.5network resources are used as efficiently as possible;  p. 64
B.5.1Always-on:  p. 64
B.5.2NRCA:  p. 64
B.5.3Conclusion  p. 65
B.6Minimum investment  p. 65
B.6.1Always-on:  p. 65
B.6.2NRCA:  p. 65
B.6.3Conclusion  p. 65
B.7Minimum operating cost  p. 66
B.7.1Always-on:  p. 66
B.7.2NRCA:  p. 66
B.7.3Conclusion  p. 66
B.8interoperability and Service availability when roaming  p. 66
B.8.1Always-on:  p. 66
B.8.2NRCA:  p. 66
B.8.3Conclusion  p. 66
B.9Charging  p. 67
B.10Type of IP addresses used  p. 67
B.10.1NRCA with static addresses  p. 67
B.10.2NRCA with dynamic address and MSISDN addressing  p. 67
B.10.3Always-on:  p. 67
B.10.4Conclusion  p. 67
B.11FINAL Conclusion  p. 68
CComparison of NRCA and SMS as a push solution  p. 68
C.1Introduction  p. 68
C.2MM signalling required  p. 68
C.3Signalling during push delivery  p. 68
C.4Conclusion  p. 70
$Change history  p. 70

Top