1. M2M Service Session Management (SSM) CSF Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP8 Agenda Item:

2. Outline © 2013 oneM2M Partners oneM2M-ARC-0397R01 2 M2M Service Session Management (SSM) CSF – SSM CSF capabilities – SSM resources – SSM stage-2 message flows – Relationship of SSM with other CSFs

3. SSM CSF Capabilities SSM CSF manages M2M service session – Supports establishing/terminating M2M service sessions – Supports different types of M2M service sessions Service sessions with session control and data flowing through CSE (e.g. small data) Service sessions with only session control flowing through CSE (e.g. video streaming) – Supports M2M service session policies Definition of M2M service session policies hosted by CSE (e.g. store-and-forwad) Configuration of underlying network session policies (e.g. via 3GPP Rx/PCRF) – Supports M2M service session context and generation of events Definition of CSE-generated service session context and events – E.g. rate, number, or distribution of requests per session, duration of time that a session is active, etc. Collection/configuration of underlying network generated session context and events – Supports coordinating with other CSFs to support service sessions Collaborate with NSE and CMDH CSFs to manage underlying network connections, policies, and services required for end-to-end service session Collaborate with other CSFs such as DMR, SEC, SCA, etc Note – SSM CSF only applicable for use cases that require a service session

4. SSM Resources © 2013 oneM2M Partners oneM2M-ARC-0498R01 4 New attributes for

5. New attributes for © 2013 oneM2M Partners oneM2M-ARC-0498R01 5 AttributeDescription sessionCapableDefines whether AE is capable of service-session based communication (TRUE or FALSE) sessionInviteUsed to invite an AE to join a service session. To invite a AE to join a service session, this attribute is updated with the URI of a resource which the AE is invited to join. An AE can subscribe to updates to this attribute and in turn receive notifications for each service session invitation.

6. © 2013 oneM2M Partners oneM2M-ARC-0498R01 6

7. © 2013 oneM2M Partners oneM2M-ARC-0498R01 7 AttributeDescription sessionIDA unique ID is assigned by SSM CSF when M2M service session is established (i.e. when resource is created). credentialsCredentials used by the session participants (e.g. to perform E2E security (e.g. authentication, encryption/decryption of service session data, etc). Editor’s note: Need to further discuss viability of CSE managing service session credentials and storage within resource.. stateUsed to observe and control the operational state of M2M service session of all the participants. participants List of identifiers of M2M service session participants. For participants that are AEs, application identifier (App-ID) is used. For participants that are CSEs, CSE identifier (CSE- ID) is used. policyLinksList of URIs of M2M service session policy resources associated with this service session

8. © 2013 oneM2M Partners oneM2M-ARC-0498R01 8 AttributeDescription rulesDefines rules for service session management. Service session context collection rules Service session request processing rules CMDH delivery parameter configuration rules Rules for SSM CSF interaction with underlying network Editor’s Note: Supported rules and format of rules is FFS.

9. © 2013 oneM2M Partners oneM2M-ARC-0498R01 9 AttributeDescription type Used to select the type of service session context that the SSM stores within the ‘context’ attribute. SSM also supports policy-based context collection by configuring this attribute with a URI that references a resource defining a set of context collection rules. Editor’s Note: Supported native context types and format of context is FFS. context Service session context information collected by SSM. Type of collected context is defined by ‘type’ attribute.

10. SSM Procedures © 2013 oneM2M Partners oneM2M-ARC-0498R01 10 Service Session Establishment Service Session Based Communication – Small data session flowing through CSE – Media session data bypassing CSE Service Session Termination Note: The given procedures are for understanding the functionalities of SSM CSF. Detail procedures are FFS.

11. Service Session Establishment CSE1 AE1 CSE2 AE2 AE1 creates resource Response (sessionID, sessionCredentials) AE1 Registers to CSE1 Update sessionParticipants = AE1, AE2 AE2 subscribes to its sessionInvite attribute to receive session invitation notifications AE1 creates resource(s) AE1 Discovers AE2’s resource and its service session capability CSE1 creates resource on CSE2 (sessionID, sessionPolicies, sessionParticipants,…) SSM created, sessionParticipants = AE1 Service Session Policy(s) Configured*** Session Join Response (sessionID, sessionCredentials) *** Service session policy configuration MAY also involve interaction within underlying network Session Invitation Request for AE2 (sessionInvite = URI to AE1’s ) Session Invitation Response (AE2 has joined service session) AE2 Registers to CSE2 (sessionCapable == TRUE) Session Invitation Notification (URI to AE1’s ) Session Join Request (update sessionParticipants attribute w/ AE2 ) Service Session Communication Service Session Termination Session Join Response (sessionID, sessionCredentials) Session Create Response Session Join Request (update sessionParticipants w/ AE2)

12. Service Session Communication (E.g. Small Data Session Flowing Through CSE) CSE1 AE1 CSE2 AE2 Service Session Establishment SSM Service Session Termination During establishment store-and- forward policy was defined for service session ‘S1’. Based on S1’s store-and-forward policy, SSM+CMDH determine following 3 requests need to be stored by CSE1 until policy’s forwarding criteria are met (e.g. wait until off-peak hours to forward). AE1 request targeting AE2 resource on CSE2 (sessionID = S1, requestID=R1) AE1 request targeting AE2 resource on CSE2 (sessionID = S1, requestID=R2) AE1 request targeting AE2 resource on CSE2 (sessionID = S1, requestID=R3) AE1 request targeting AE2 resource on CSE2 (sessionID = S1, requestID=R1) AE1 request targeting AE2 resource on CSE2 (sessionID = S1, requestID=R2) AE1 request targeting AE2 resource on CSE2 (sessionID = S1, requestID=R3) SSM+CMDH detect policy’s forwarding criteria have been met and forward requests to CSE2... Based on S1’s service session context collection policy, SSM(s) keeps track of number of S1 requests processed (time they were received, duration of time they were stored, time they were forwarded, etc)

13. Service Session Communication (e.g., video sharing session)

14. Service Session Termination CSE1 AE1 CSE2 AE2 AE2 subscribes to CSE2’s resource to detect if/when session is terminated by AE1 Response for CSE1 that session has been terminated SSM AE1 deletes resource Delete Response Delete Notification that session has been terminated Service Session Establishment Service Session Communication Delete companion resources on CSE2 Delete

15. Relationship With Other CSFs REG CSF – REG CSF supports an AE or CSE registering to a local CSE to use its M2M services REG CSF-based registration is single-hop in nature – SSM CSF supports establishing communication relationships between AEs and/or CSEs layered over top of REG CSF M2M registration(s) Service session can be multi-hop and end-to-end in nature DMR CSF – SSM CSF collaborates with DMR CSF to service session based requests targeting CSE hosted resources SEC CSF – SSM CSF may collaborate with SEC CSF for management of service session related security credentials and authentication of session participants NSE CSF – SSM CSF may collaborate with the NGE CSF for establishment termination of Underlying Network services to support service session – This may be indirectly via CMDH SCA CSF – SSM CSF may share service session context and events with SCA CSF

16. CMDH CSF – CMDH Supports policy-based delivery of individual M2M requests between CSEs Each request has its own independent M2M-Request-ID and delivery parameters – CMDH provides communication connection controls Like ISO network model layer 4 functions – SSM CSF supports policy-based delivery of session-based requests over top of CMDH delivery of individual M2M requests (CMDH provides bearer-like mechanism for SSM) Like ISO network model layer 7 functions, e.g. SIP - SSM handles the session related capabilities which is based on underlying CMDH based connections Requests from the same service session share the same M2M-Session-ID and delivery parameters. This allows SSM CSF to manage these requests in a session-based manner. SSM CSF is a customer of CMDH CSF. SSM CSF uses session-based policies to configure CMDH delivery parameters so requests are delivered in a manner that meets the session requirements. SSM also collects/maintains service session context and generates service session events based on the service session requests it services which CMDH is not able to do since it is not aware of sessions. Note - Some non-service-session based CSFs do not need SSM and can invoke CMDH directly. Relationship With Other CSFs (con’t)

17. Relationship between SSM & CMDH CSE Mcc Mca CMDH (Communication Management and Delivery Handling) AE SSM(service sessions mgmt.) NSE(Underlying Network Services Entity ) DMR Mcn non-service-session based communication request service-session based communication request Other CSFs

18. Next Steps © 2013 oneM2M Partners oneM2M-ARC-0498R01 18 Reach consensus on SSM concepts and capabilities – Based on approved use cases and requirements Reach consensus SSM resources and procedures Reach consensus on SSM relationship with other CSFs