oneM2M TS-0006Release Notes diff from v5.0.1 to v5.0.0oneM2M TS-0006Release Notes diff from v5.0.1 to v5.0.0This clause specifies how the IN-CSE interacts with an ACS in order to manage the Resources described in the present document. The IN-CSE interaction with an ACS includes:
NOTE: The Broadband Forum has not defined a protocol specification for the Northbound Interface of an ACS. As such, the present document only describes the expectations of this interface in the form of requirements on the ACS.
When the IN-CSE detects that it has to delegate an interaction with a device resource to an ACS, the IN-CSE establishes a communication session with the ACS. The establishment of a communication session between the IN-CSE and ACS provides security dimensions for Access control, Authentication, Non-repudiation, Data confidentiality, Communication security, Data integrity and Privacy adhering to the followingBBF TR-131 [7] Architectural requirement A7.
The IN-CSE may establish multiple sessions with an ACS based on the security model utilized between the IN-CSE and the ACS.
When the ACS detects a change to resources it manages that the IN-CSE has expressed interest, the ACS requests the IN-CSE to establish a session if a session does not exist for the resource being managed. The establishment of a communication session between the IN-CSE and ACS provides security dimensions for Access control, Authentication, Non-repudiation, Data confidentiality, Communication security, Data integrity and Privacy adhering to the followingBBF TR-131 [7] Architectural requirement A7.
The ACS may establish multiple sessions with an IN-CSE based on the security model utilized between the IN-CSE and the ACS.
While a session between the ACS and IN-CSE is not established, the ACS retains any notifications or changes in the resources based on an Event retention policy (i.e. time, number of events).
When an ACS to IN-CSE interaction is required and a session does not exist, the ACS requests to initiate a session based on a Session Initiation Policy (i.e. Periodic contact establishment (schedule), upon event detection with timeframe window).
When establishing a session from the ACS to the IN-CSE:
Requests and Notifications mechanisms between the IN-CSE and the DM Server format the XML schema of the CPE methods defined in BBF TR-069 [4] as an ACS would format the CPE methods that it would pass to the CPE. The IN-CSE would then also process the CPE methods as defined in BBF TR-069 [4]. Likewise the ACS would send notifications in the format of the XML schema of the CPE for sending events using the Inform RPC.
When receiving requests from the IN-CSE the ACS shall be capable of defining mechanisms to support triggering of immediate operations to device. If the device is not available the ACS returns an appropriate error code.
The ACS shall provide capability for the IN-CSE to indicate request policies to include: Retry policy, Request Time out.
When sending notifications to the IN-CSE:
For devices under management, the IN-CSE may discover resources of interest (metadata and values) within a device using the ACS.
For resources of interest, the IN-CSE may also express an interest to be notified of a resource if a resource is changed (added, deleted, updated).
The IN-CSE shall be capable to discover and subscribe to changes of resources in order to synchronize the IN-CSE with resources of interest of the ACS.
Once a request has performed an Access Decision by the IN-CSE to allow the request, the IN-CSE shall select the appropriate ACS along with elements the ACS would need to implement access management within the ACS. These would include the Identity of the subject (oneM2M Originator) of the request which is needed in scenarios where the original issuer of the request is needed to be known - this could be done by correlating principals (e.g. Roles, Accounts) used by the IN-CSE and ACS.