RCS Workshop - PGM PA2

Rogers RCS
workshop
PGM
PGM
SUMMARY:
• PGM Architecture
• Network Address Book Architecture and client aspects
• S-CAB flows
• Service Capabilities & OMA Presence (RCS Social Presence
Information) flows
Presence, Service Capabilities and Network

Address Book
Rogers Network VoLTE+RCS
CS (SMS) Core
(SMS)
Legacy TBD (API) CAP E/Gd SMPP MM4
NAB
SynchML
Sh/J/S6c
To all
HSS / IP-SM- SMPP MMS relevant
HLR GW IWF IWF elements Provisi
Zh/Zx oning
CS+RCS
RCS Sh
Config. CPM-IW2 EMe
Mobile HTTP
MTAS
SCC-AS RCS CPM-PF1
Ut CPM-PF1 ISF
AP Ut’
CNP PGM
CPM-IW1 CPM-IW1 To all
XDMS
relevant
VoLTE+RCS
elements CDF
Mobile XDM-4i
CardDAV
SCAB Presence
RCS PF RCS CF
CPM-MSG
Message
To other
Gm Store networks
ISC
RCS+
PC/Tablet IMS Core
New functionality required Optional functionality

PA2 | Commercial in confidence | © Ericsson AB 2014 | 2014-01-31 | Page 3 (31)
for the RCS solution
ERIcsson PGM logical components
Other IMS
network
GMLC
MLP
PGM
CSCF
Location
Client
RLS PS
SIP HSS PNA
Client FW
XCAP/
HTTP
AFG PGM XDMS

Capabilities AU Directory AU
AP
Presence Rules AU Persistent Presence AU Content AU
RLS Services AU Resource Lists AU Personal Contact Card AU

HTTP/HTML
Self Admin
Group AU Access Rules AU Group Usage List AU
Portal
XDM FW

Integration with rogers assets
(Incumbent NAB)
SyncML
Other IMS Server
network TBD
GMLC XCAP or APIs?

SyncML
MLP
PGM
CSCF Integration
Location
Data converter
Client
SIP HSS RLS PS PNA framework
Client FW
XCAP/
HTTP
AFG PGM XDMS

AP

HTTP/HTML
Self Admin
Portal
XDM FW

Network Address
Book Architecture
and
client aspects
PGM NAB View for Rogers
PGM NAB
Incumbent
NAB
SyncML
SIP/XCAP
** If no downloadable clients

NAB and client view
› Native address book vs Rogers address book
– Limited to data set available in the platform address book
– Native address books in feature phones:
› Syncml natively, use vCard early versions w/ limited data set
– Native address books in smartphones & open platforms devices
› IOS – low API exposure for add-ons to native address book
› Android – more open, but still an alternative view of the address book is needed
with the additional enhancements
› Why a Rogers address book as alternative view to the

native address books makes sense:
– Apples with Apples, Androids with Androids. Roger’s Address Book synch’s across
all devices
– Enables addition of new operator services such as RCS ecosystem (service
capabilities, presence and Ux to launch RCS services).
– Enhanced contacts data set in the address book.

Proposed approach-
clients
› Goal: Centralized address book data for user from all devices
› Feature phones:
– integrate with incumbent syncml server in the network (TBD- via XCAP or API) –
absorb the contacts synchronized via syncml into the central contacts DB (PGM
XDMS)
› Smartphones/ Open platforms devices:

– downloadable Rogers client includes also S-CAB client functionality
– if no downloadable Rogers client is foreseen, then use the CardDAV native synch
from the IOS & Android to synch up data to PGM CardDAV server (roadmapped).
PGM integrates all contacts into the Address Book XDMS.
› Address Book integration of Social Networking Services:

– Current solution: devices already have direct SNS integration (Facebook, etc).
– Future (as needed, per SNS basis): next releases PGM will offer the network
integration to SNSs (implies Rogers direct licensing/business agreement with the
SNS providers):
› Simple for user, better service usability on clients (eliminates the need to
download/preloaded & configure SNS specific clients on device)
Multi-device
› RON identities handling
– Different device identities used towards same set of user documents in XDMS, or
towards Presence Server
› the requestor identity: each user device should use the main IMPU in:
- XCAP (in 3GPP-I-I or username=IMPU)
- SUBSCRIBE (client populates main IMPU - into P-P-I -> to be ultimately
populated by CSCF into P-A-I which is used by XDMS for authorization
checks)
- PUBLISH (client uses main IMPU in the R-URI, “entity” attribute, in P-P-I ->
populated by CSCF into P-A-I which is checked by PS)
› the contact’s identity: when target is another user’s Presence data or XDM
resources, it can be expected to use the identity available in the contact’s info
(main IMPU):
- XCAP (use it as the XUI in R-URI)
- SUBSCRIBE (R-URI; also coming from the entries within the presence lists
e.g. vip, non-vip, etc)
- Access Permissions: need to include the watcher’s main IMPU (if available in
the contact’s info, else need to list all RON identities for that user)

PGM Central Network Address book vision
(Incumbent NAB)
SyncML
Other IMS Server SNSs
network TBD
.....
HTTP
REST/
GMLC XCAP or APIs?
SyncML
MLP
PGM
CSCF
Location
Data converter
Client S-CAB IW
SIP HSS RLS PS PNA framework
SN FW
Client FW
XCAP/
HTTP
AFG PGM XDMS

AP

HTTP/HTML
Self Admin
Portal
XDM FW

Planned S-CAB
Implementation
Phase 1 – network Address book synch
with all user devices
Phase 2- other S-CAB features (based
on operator input)
Example flows: Address
book synch uc (via xcap)
› Flow 1: User has a new device, the entire address book is restored on
client
– The client’s local address book is empty. The entire network address book is
fetched.
› Flow 2. Add new contact

– A new contact is added to the network address book
› Flow 3. Modify a contact (e.g. <display-name> for a contact is modified).
› Flow 4 . Delete a contact

– A contact is removed from the address book.
› Flow 5. The client is synchronizing the local address book with the
network address book using regular polling (XCAP GET).
Note: XDM AP and IMS Core are not shown in the flows. All HTTP requests are send via XDM AP and all SIP Request via
IMS Core.
S-CAB Data Model -
XML schemas
S-AB Contact Card
S-CAB
PCC (Personal Contact Card)
extensions
Person-Details Org-Details Group-

Update Contact Type
element [0,m] element [0,n] Details Object List] Element (S-
element [0,p] CAB/CAB, source, mutual
status)
-index
-tcc-ref
-iuo-ref
-timestamp
Elements:
Update -prio
Elements: Elements:
Name, Name, Name, Object -approval
element [0,r] -update-type
address, etc address, etc address, etc -source-name
-contact-subscription-
status
-import-status
-export-status
Flow 1: NEW device (Fetch NAB, Local AB empty)
S-CAB Client S-AB App Usage
1. Get S-AB AU folder in the XDM Directory Document.

HTTP GET /org.openmobilealliance.xcap-directory/users/xui/directory.xml/~~/xcap-directory/
folder%5B@auid=%22org.openmobilealliance.s-cab-address-book%22%5D
2. OK Response
HTTP/1.1 200 OK
NOTE: Content-Type: application/xcap-el+xml; charset="utf-8"
Content-Length: (...)
the <folder auid="org.openmobilealliance.s-cab-address-book">
<entry uri="/org.openmobilealliance.s-cab-address-book/users/xui/carl.ericsson" etag="pqr999"/>
Aggregation <entry uri="/org.openmobilealliance.s-cab-address-book/users/xui/joe.ericsson" etag="fqr4567"/>
<entry uri="/org.openmobilealliance.s-cab-address-book/users/xui/bob.ericsson" etag="hqr5675"/>
Proxy not </folder>
shown for
3. Get Carl Ericsson’s Contact Card.
simplification HTTP GET /org.openmobilealliance.s-cab-address-book/users/xui/carl.ericsson
4. Response with Carl Ericsson’s Contact Card

HTTP/1.1 200 OK
Content-Type: application/vnd.oma.cab-pcc+xml; charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?>
<pcc pcc-type="individual" xmlns="urn:oma:xml:cab:pcc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:sc10="urn:oma:xml:scab:1.0extensions">
<person-details........
</pcc
5. Get Joe Ericsson’s Contact Card.

HTTP GET /org.openmobilealliance.s-cab-address-book/users/xui/joe.ericsson
6. Response with Joe Ericsson’s Contact Card

HTTP/1.1 200 OK
</pcc
7. Get Bob Ericsson’s Contact Card.

HTTP GET /org.openmobilealliance.s-cab-address-book/users/xui/bob.ericsson

HTTP/1.1 200 OK
</pcc

Flow 2: ADD new contact Card in NAB
NOTE: the Aggregation Proxy not shown for simplification
1. Add Alice Ericsson’s Contact Card.

HTTP PUT /org.openmobilealliance.s-cab-address-book/users/xui/alice.ericsson
...
<pcc pcc-type="individual" xmlns="urn:oma:xml:cab:pcc" xmlns:xsi="http://www.w3.org/2001/
XMLSchema-instance" xmlns:sc10="urn:oma:xml:scab:1.0extensions">
</pcc
2. Response with etag information for the new contact card.

HTTP/1.1 201 Created
Etag: hstdeet4555

Flow 3: Modify a Contact Card in NAB
1. Udate Alice Ericsson’s Contact Card with a new display name.

HTTP PUT /org.openmobilealliance.s-cab-address-book/users/xui/alice.ericsson/~~/pcc/person-
details/name%5B@index=%22abc%22%5D/name-entry%5B@index=%22def%22%5D/display-
name
If-Match: hstdeet4555
Content-Type: application/xcap-el+xml; charset="utf-8"
<display-name>Lovely Alice</display-name>
2. Response with etag information for the modified contact card.

HTTP/1.1 200 OK
Etag: hstdeet6789

Flow 4: Removal of a Contact Card from NAB
1. Delete Carl Ericsson’s Contact Card.

HTTP DELETE /org.openmobilealliance.s-cab-address-book/users/xui/carl.ericsson
...
IF-Match: pqr999
2. Positiv Response: Delete was successful as the received etag value was matching the value stored inNAB.
HTTP/1.1 200 OK

Flow 5: Synchronization using XCAP Get polling
1(2)
S-CAB Client CASE 1: Client is performing next regular/on-demand check. S-AB App Usage

2. OK Response
HTTP/1.1 200 OK
<folder auid="org.openmobilealliance.s-cab-address-book">
Client <entry uri="/org.openmobilealliance.s-cab-address-book/users/xui/joe.ericsson" etag="fqr4567"/>
<entry uri="/org.openmobilealliance.s-cab-address-book/users/xui/bob.ericsson" etag="hqr5675"/>
compares local </folder>
etag values
with the ones 3. Get Carl Ericsson’s Contact Card as local address book is empty.
HTTP GET /org.openmobilealliance.s-cab-address-book/users/xui/carl.ericsson
received
4. Response with Carl Ericsson’s Contact Card
HTTP/1.1 200 OK
</pcc
5. Get Joe Ericsson’s Contact Card as local address book is empty.

HTTP GET /org.openmobilealliance.s-cab-address-book/users/xui/joe.ericsson

HTTP/1.1 200 OK
</pcc
7. Get Bob Ericsson’s Contact Card as local address book is empty.

HTTP GET /org.openmobilealliance.s-cab-address-book/users/xui/bob.ericsson

HTTP/1.1 200 OK
</pcc

Flow 5: Synchronization using XCAP Get polling
2(2)
S-CAB Client A S-AB App Usage
CASE 2: The User’s S-CAB Client B has added Alice contact card as shown in flow 2.
Client is performing next regular check

2.OK Response
HTTP/1.1 200 OK
<entry uri="/org.openmobilealliance.s-cab-address-book/users/xui/joe.ericsson" etag="fqr4567"/>
<entry uri="/org.openmobilealliance.s-cab-address-book/users/xui/bob.ericsson" etag="hqr5675"
<entry uri="/org.openmobilealliance.s-cab-address-book/users/xui/alice.ericsson" etag="hstdeet4555"/>
Client </folder>
compares local 3. Get Alice Ericsson’s Contact Card as it is added since last check.
HTTP GET /org.openmobilealliance.s-cab-address-book/users/xui/alice.ericsson
etag values
with the ones 4. Response with Alice Ericsson’s Contact Card
HTTP/1.1 200 OK
received Content-Type: application/vnd.oma.cab-pcc+xml; charset="utf-8"
</pcc
CASE 3: The User’s S-CAB Client B has changed Alice Display name in the contact card as
shown in flow 3.
Client is performing next regular check

HTTP/1.1 200 OK
<entry uri="/org.openmobilealliance.s-cab-address-book/users/xui/joe.ericsson" etag="fqr4567"/>
<entry uri="/org.openmobilealliance.s-cab-address-book/users/xui/bob.ericsson" etag="hqr5675"
<entry uri="/org.openmobilealliance.s-cab-address-book/users/xui/alice.ericsson" etag="hstdeet6789"/>
Client </folder>
compares local 2. Get Alice Ericsson’s Contact Card as the etag value has changed since last check.
etag values HTTP GET /org.openmobilealliance.s-cab-address-book/users/xui/alice.ericsson
with the ones 3. Response with Ailce Ericsson’s Contact Card

HTTP/1.1 200 OK
received Content-Type: application/vnd.oma.cab-pcc+xml; charset="utf-8"
<pcc.....
</pcc

Service capabilities –
Presence based
PGM PGM IMS Core PGM PGM
RCS A IMS Core (Presence XDMS A (Presence RCS B
B XDMS B SME B CPM C
A Server) Server)
1. SIP SUBSCRIBE(ReqURI:tel:userB,From: Anonymous@anonymousdomain,Privacy:id,P-Preferred-ID:<>,expires:0) Pre-condition:

User B has published
his service capabilities
1.a SIP SUBSCRIBE
Authorization 1.b SIP SUBSCRIBE
2. HTTP: Retrieve rules Only if Presence Server

hasn’t previously
2.a. HTTP: 200 OK (<rules retrieved the rules
document>)
** Rules indicate
anonymous user is allowed
3a. SIP 200 OK 3. SIP 200 OK to see service capabilities
3b. SIP 200 OK
4. SIP NOTIFY
(services for user
4a. SIP NOTIFY B)
4b. SIP NOTIFY
5. 200 OK (…)
5a. 200 OK (…)
5b. 200 OK (…)
Final NOTIFY containing

only service tuples
The RCS user B is not a VIP contact for user A, or there is no presence relationship established between user A and B.

Current NAB in PGM:
PCC Update and distribution to
watchers through presence
› User on UE-B = watcher, subscribed to presence event package, to User on UE-A
Presence
UE A PCC AU UE B
Server
Name: Alice
HTTP/XCAP PUT (Update PCC)
Surname: Smith
Phone: +1-555-0100
200 OK (ETag=5)
HTTP/XCAP PUT (Update Presence: link + ETag)
200 OK
SIP NOTIFY (A: link + ETag)
200 OK
The client detects
that the ETag has
HTTP/XCAP GET (Retrieve updated PCC from A) been updated
The PCC AU
checks if B is 200 OK Name: Alice
authorized Surname: Smith
Phone: +1-555-0100

Presence and
service
capabilities
Presence – high level concept
Presentity Watcher Watcher IMS PS
PS
A B C CORE XDMS
1. SUBSCRIBE(A)
Check trigger
2. Fetch auth.rules
Authorize B
3. NOTIFY(A=empty)
4. PUBLISH(A)
Check trigger
Store data and
5. NOTIFY(A’s data) Notify watcher
6. SUBSCRIBE(A)
Check trigger
Authorize C
7. NOTIFY(A’s data)
8. PUBLISH(A)
Check trigger
Store data and
9. NOTIFY(A’s data) Notify watchers

Presence – RLS Use Case
Presentity IMS RLS PS
RLS PS
A CORE XDMS XDMS
1. SUBSCRIBE(list) Check trigger

2. Resolve List
List=A,B
3. SUBSCRIBE(B) 4. Fetch auth.rules
5. NOTIFY(B’s data) Authorize A
6. SUBSCRIBE(C) 7. Fetch auth.rules

8. NOTIFY(C’s data)
Authorize A
9. NOTIFY(A+B’s data)
Store data and

10. PUBLISH(B) Check trigger Notify watcher
11. NOTIFY(B’s data)

12. NOTIFY(B’s data)

Presence – Presence Data
Composition
Presentity
Watchers
PS
Raw Presence
Document
Presence
Source
Final Presence
Documents
Documents
Populating Composition Rules & Filter

Presence Process Process
Data
Presence – Presence Data
Composition
Presence Server
Candidate Raw
Presence Candidate
Presence Presence Presence Content
Presence
Presence Publish Presence Composition
Source Publish
Publish Presence Document Rules Process
Source Sources
Document
Source Document Process
Documents
Filtered
Filtered Candidate
Transformed
Final Watcher Candidate
Candidate
Presence
Presence Watcher Presence
Watcher Publish Throttling
Rate
Event Notify Presence Watcher
Filtering Presence
Presence
Watcher
Watcher Publish Throttling Notify
Notify Document Filtering Document
Publish
Notify Limitation Document
Document Filtering Document
Throttling Document

Presence – Subscribe to
Winfo Use Case
Presentity Watcher Watcher IMS PS
PS
A B C CORE XDMS
1. PUBLISH(A)
Check trigger
Store data
2.SUBSCRIBE(Winfo)
Check trigger
3. NOTIFY(Winfo:empty)
4. SUBSCRIBE(A) Check trigger

5. Fetch auth.rules
No rule for B
6. Notify(pending)
7. NOTIFY(Winfo:B=pending)
8. Update auth.rules
9. Notify new rules

11. NOTIFY(Winfo:B=active)

rCS flows
RCS service capability and SPI
Publication
• via SIP PUBLISH as per RCS for service caps,
IMS
Domain A Core Domain B
optional for SPI)
User A User A User B User B
device1 Device 2 device1 device2
› Using SIP PUBLISH

RCS SPI Publication (2)
• via XCAP (as per RCS for SPI) Domain A
IMS
Domain B
Core
› Using XCAP
Device 2 adjusts its Social

Presence data and UI to the
latest social Presence from the
aggregated document

Portrait icon update IMS
Domain A Domain B
Core
User A updates Portrait icon from device 2

Authorization of SPI Subscription
IMS
Domain A Domain B
Core

Capabilities through Anonymous
subscribe
IMS
Domain A Domain B
Core
The RCS user B is not a VIP contact for user A, or there is no presence relationship established between user A and B.
Capability Discovery
joyn/RCS5.1 OPTIONS-based
Example: All contacts subject to RCS service discovery by SIP OPTIONS
Originating Terminating
IMS IMS
B C D E
A
B is RCS
D is not RCS
C is RCS
E is RCSr
 A new added contact can be subject to RCS service discovery.

 Response includes what RCS services are supported
In order to allow Rogers to understand and assess the strength and suitability of Ericsson’s RCS offering in future RCS deployment in Rogers’ Network, we would appreciate the
opportunity to have a technical workshop with Ericsson. Our expectation is the workshop to happen in early February.
We envision our RCS deployment scope to be based on RCS 5.1 v4 and NARCS feature profile (E, All), with capabilities discovery based on PRESENCE simple (A), and OMA CPM
based messaging (B) (see attached NARCS minimum Features Set) (E, All)
Please see below a brief list of topics we are interested in:
• Vendor’s RCS solution and its components. (E, All)
• Architecture level mapping between vendors’ product components and RCS functional entities as described in industry specs (3gpp/OMAS/GSMA) (E, All)
• What parts of vendor’s solution and features are available today , at the end of the year, and in long term. (E, All)
• Discuss the specifications evolution and vendor’s view on it - RCS 5.1 , 5.2 , 6.0 (lower priority ). (E, All)
• How vendor’s solution will utilize and integrate with existing Rogers’ assets - IMS core (A, B), MMTEL AS (B), SMSC (B), IP-SM GW (B, D) address books (A)
• Details about vendors implementation and support of the following (ordered in priority):
1. Solution for Capability and User discovery (A)
• “Capability and Presence Enhanced” Address Book (social presence is low priority) based on OMA Presence Simple and Shared XDMS (A)
2. Solution for device management including auto configuration (C)
3. Solution for messaging, chat (1-1 and group), File Transfer and Image Share. (B)
• Enabled with Store and Forward capability (B)
• Integration aspects with existing Rogers SMCS , MMSC , IP-SM-GW and Converged Message Store needed to be addressed as well (B)
4. Solution for Geo Location (lower priority) (A) (?)
5. Solution for video share (lower priority) (D)(?)
• Integration aspects with existing Rogers MMTel AS. Video Calling interworking (D)(?)
6. Solution for Personal Network Blacklist (PNB) for applicable RCS services as per RCS 5.1 2.15.1 (B, D)
7. Multi-device support (All)
• For each of the RCS services supported by vendor: (All)
a. Provide an architectural diagram illustrating the functional components required, integration between the components and with external components, including existing
Network Elements within Rogers’ network. (All)
b. Specify the protocol used in each integration point. (All)
c. Provide call flow walkthrough for major use cases (All) – must demonstrate i/w with legacy messaging (B) A – Presence & Address Book
d. Describe how charging of the service is covered. (All)
e. Describe the subscriber provisioning process if subscriber provisioning is required for the service. (All)
B – Messaging
f. Describe if the service is supported using Downloadable or embedded Client. (All)
C – ADC/OMA-DM
g. Describe if any area in implementation of service is not standard compliant. (All)
• Other applicable topics, at vendor’s discretion (All) D – MTAS & IMS Core
Please let us know Ericsson’s availability/possible dates for this. E – Overall & Standardization

All – A & B & C & D & E
Tentative agenda
1. 10:00-10:15 - Introductions (Pieter)
2. 10:15-10:45 - Rogers RCS vision (Rogers)
3. 10:45-11:45 - Ericsson RCS solution : Commercial
presentation (Lennart L.).
4. 11:45-12:45 LUNCH
5. 12:45-13:45 Rogers RCS E2E solution Overview -
Ericsson view. (Sorin)
6. 13:45-15:00 – EME (Anders L. / Ayoub)
7. 15:00-15:15 BREAK
8. 15:15-16:30 – PGM (Cristina)
9. 16:30-17:00 - RCS configuration Server (Tamir)
10. 17:00-17:30 - Conclusion and Discussions – 30 min
Tentative agenda
Details
1. 10:00-10:15 - Introductions (Pieter)
2. 10:15-10:45 - Rogers RCS vision (Rogers)
– Rogers to present RCS vision, NA profile, Canadian Profile etc
3. 10:45-11:45 - Ericsson RCS solution : Commercial presentation (Lennart L.)
– Ericsson to present RCS market situation, Ericsson RCS solution maturity and superiority
– Client strategy, Charging Models, Interoperability in other markets.
4. 11:45-12:45 LUNCH
5. 12:45-13:45 Rogers RCS E2E solution Overview - Ericsson view. (Sorin)
– Show our deep knowledge of Rogers network
– Start with VoLTE + RON baseline (15 A)
› Show a reference architecture including SynchML-AB (VoxMobiliy) IP-SM-GW (Converse)
– Add the logical functionalities / interfaces needed for RCS
› CPM-PF, CPM-CF, CPM-ISF, CPM-Message-Store, SCAB, RCS configuration Server
– Cover Call Flows A and B:
6. 13:45-15:00 – EME (Anders L. / Ayoub)
– Cover call flow H (and eventually I)
7. 15:00-15:15 BREAK
8. 15:15-16:30 – PGM (Cristina)
– Cover Call flows E and F
9. 16:30-17:00 - RCS configuration Server (Tamir)
– Eventually cover call flow C
10. 17:00-17:30 - Conclusion and Discussions – 30 min
› NOTE : The slides for each Ericsson solution components should include:
– Technical aspects (mapping to reference architecture, Interfaces etc.) , Charging, Provisioning, Roadmap ( Presenter to
decide the relevant content), Relevant call flows. Please review slide customer request on slide 17 –last first level
bullet.
– How the node will integrate in Rogers network.

Call flows
Wish List
A. Discussion on the types of terminal / clients for RCS (downloadable ,
embedded)
– Here we need to have a discussion about VoLTE + RCS messaging evolution.
We don’t have a clear story but we can say we are working on it and will
present the findings in a subsequent workshop
B. Data model assumption
– same as we proposed to Rogers for RON
C. RCS client download and configuration process
D. Registration of one user from 2 devices/ 3 clients (as discussed with
Elaine):
– One Primary device FLT (VoLTE or CS) + downloadable RCS (P-RCS Voice)
› VoLTE + Wi-Fi accesses (home)
– One secondary device – PC/Tablet on Wi-Fi (home)
E. Address book synchronization
F. Capability discovery / Social Presence using Presence
– User A has B and C in the address book B is non-RCS, C is RCS

VoLTE + “RCS+” Data model
Rogers network
Subscription
IMS Subscription
IRS
IMPI1-1- VoLTE IMPU1-1 (IMSI based)- barred
(IMS AKA)
IMPU1-2 (for ICS)- barred
•IMPU 16-1 and IMPU 16-2 IMPI1-2 - eMSC IMPU1-3 (sip:MSISDN1)- main
were added to support RON (no auth) Orig & Term iFC
IMPU1-4 (tel:MSISDN1)
specific:
•call all IMPU2-1 (sip:MSISDN2)
•call one-mobile IMPI2 – RON IP1
(digest) IMPU2-2 (tel:MSISDN2) Orig & Term iFC
•They are defined as sip:uri
(PC/Tablets)
•They are not defined in IMPU3-1 (sip:MSISDN3)
ENUM IMPI3 – RON IP2 IMPU3-2 (tel:MSISDN3) Orig &Term iFC
(digest)
(downloadable client)
IMPU16-1 (sip:call_mobile_id)
IMPU16-2 (sip:call_all_id)
One Call Back Number for
each RCS IP voice devices
CS Subscription MSISDN1

RCS Workshop - PGM PA2

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

RCS Workshop - PGM PA2

Diunggah oleh

Hak Cipta:

Format Tersedia

Rogers RCS

Presence, Service Capabilities and Network

Legacy TBD (API) CAP E/Gd SMPP MM4

New functionality required Optional functionality

AFG PGM XDMS

RLS Services AU Resource Lists AU Personal Contact Card AU

PA2 | Commercial in confidence | © Ericsson AB 2014 | 2014-01-31 | Page 4 (31)

GMLC XCAP or APIs?

AFG PGM XDMS

RLS Services AU Resource Lists AU Personal Contact Card AU

PA2 | Commercial in confidence | © Ericsson AB 2014 | 2014-01-31 | Page 5 (31)

PA2 | Commercial in confidence | © Ericsson AB 2014 | 2014-01-31 | Page 7 (31)

› Why a Rogers address book as alternative view to the

PA2 | Commercial in confidence | © Ericsson AB 2014 | 2014-01-31 | Page 8 (31)

› Smartphones/ Open platforms devices:

› Address Book integration of Social Networking Services:

PA2 | Commercial in confidence | © Ericsson AB 2014 | 2014-01-31 | Page 10 (31)

AFG PGM XDMS

RLS Services AU Resource Lists AU Personal Contact Card AU

PA2 | Commercial in confidence | © Ericsson AB 2014 | 2014-01-31 | Page 11 (31)

› Flow 2. Add new contact

› Flow 3. Modify a contact (e.g. <display-name> for a contact is modified).

› Flow 4 . Delete a contact

Person-Details Org-Details Group-

1. Get S-AB AU folder in the XDM Directory Document.

4. Response with Carl Ericsson’s Contact Card

5. Get Joe Ericsson’s Contact Card.

6. Response with Joe Ericsson’s Contact Card

7. Get Bob Ericsson’s Contact Card.

8. Response with Joe Ericsson’s Contact Card

PA2 | Commercial in confidence | © Ericsson AB 2014 | 2014-01-31 | Page 15 (31)

S-CAB Client S-AB App Usage

1. Add Alice Ericsson’s Contact Card.

2. Response with etag information for the new contact card.

PA2 | Commercial in confidence | © Ericsson AB 2014 | 2014-01-31 | Page 16 (31)

S-CAB Client S-AB App Usage

1. Udate Alice Ericsson’s Contact Card with a new display name.

2. Response with etag information for the modified contact card.

PA2 | Commercial in confidence | © Ericsson AB 2014 | 2014-01-31 | Page 17 (31)

S-CAB Client S-AB App Usage

1. Delete Carl Ericsson’s Contact Card.

PA2 | Commercial in confidence | © Ericsson AB 2014 | 2014-01-31 | Page 18 (31)

1. Get S-AB AU folder in the XDM Directory Document.

5. Get Joe Ericsson’s Contact Card as local address book is empty.

6. Response with Joe Ericsson’s Contact Card

7. Get Bob Ericsson’s Contact Card as local address book is empty.

8. Response with Joe Ericsson’s Contact Card

PA2 | Commercial in confidence | © Ericsson AB 2014 | 2014-01-31 | Page 19 (31)

1. Get S-AB AU folder in the XDM Directory Document.

1. Get S-AB AU folder in the XDM Directory Document.

with the ones 3. Response with Ailce Ericsson’s Contact Card

PA2 | Commercial in confidence | © Ericsson AB 2014 | 2014-01-31 | Page 20 (31)

1. SIP SUBSCRIBE(ReqURI:tel:userB,From: Anonymous@anonymousdomain,Privacy:id,P-Preferred-ID:<>,expires:0) Pre-condition:

1.a SIP SUBSCRIBE

Authorization 1.b SIP SUBSCRIBE

2. HTTP: Retrieve rules Only if Presence Server

Final NOTIFY containing

PA2 | Commercial in confidence | © Ericsson AB 2014 | 2014-01-31 | Page 21 (31)

HTTP/XCAP PUT (Update Presence: link + ETag)

PA2 | Commercial in confidence | © Ericsson AB 2014 | 2014-01-31 | Page 22 (31)

10. NOTIFY(A’s data)

PA2 | Commercial in confidence | © Ericsson AB 2014 | 2014-01-31 | Page 24 (31)

1. SUBSCRIBE(list) Check trigger