7.6 Configuration of Traffic Patterns

oneM2M uses the 3GPP MTC feature for Configuration of Device Communication Patterns to configure Node Traffic Patterns in the underlying 3GPP network (see clause 8.3.5 Configuration of Node Traffic Patterns of oneM2M TS-0001 [1]).

To that purpose the IN-CSE translates the oneM2M Node Traffic Pattern (TP) into a 3GPP Device Communication Pattern. The generic oneM2M procedure for configuration of Node Traffic Patterns is shown in Figure 7.6-1.

The underlying 3GPP network signalling sequence for provisioning of CP parameters is described in 3GPP TS 23.682 [2].

Figure 7.6-1: General procedure for oneM2M configuration of Traffic Patterns

Figure 7.6-1: General procedure for oneM2M configuration of Traffic Patterns

Pre-conditions:

There is a relationship in place between the IN-CSE and MNO allowing the IN-CSE to request Configuration of Device Communication Patterns. The method for establishing this relationship is outside the scope of the present document.

Step 0: UE Attach and oneM2M Registration Procedures

The UE attaches to the underlying 3GPP network and the ADN-AE(s) or ASN/MN-CSE hosted on the UE perform the oneM2M registration procedure, as detailed in clause 6.3. The IN-CSE hosts the corresponding <AE> or <remoteCSE> resources and an associated <node> resource for the registree. During this procedure, the ADN-AE or ASN/MN-CSE can create an activityPatternElements attribute indicating the anticipated communication patterns.

The anticipated communication behavior of the ADN-AE or ASN/MN-CSE may also be changed by updating the activityPatternElements attribute of either the <AE> or <remoteCSE> resource, respectively.

Step 1: IN-CSE sends to the SCEF a Communication Patterns Configuration request

This step is triggered by the create/update/delete of activityPatternElements attribute of either the <AE> or <remoteCSE> resource. The IN-CSE derives the communication patterns from the activityPatternElements.

The IN-CSE selects the SCEF based on the M2M-Ext-ID's of the registree ASN/MN-CSE or ADN-AEs (e.g. either a DNS lookup on the M2M-Ext-ID or the based on the domain portion of the M2M-Ext-ID's.).

When the first activityPatternElements for a given a UE is initially configured, the IN-CSE shall generate a Communication Patterns Configuration creation request that contains the following information as specified in 3GPP TS 29.122 [4].

  • An HTTP POST method shall be used
  • URI shall be set to {apiRoot}/3gpp-cp-parameter-provisioning/v1/{scsAsId}/subscriptions. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies.
  • The request payload shall include a CpInfo data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
    • externalId shall be set to M2M-Ext-ID
    • supportedFeatures shall be set to a string value of "0" indicating no support for the expected UE geographical movement feature in the current release of this specification.
    • cpParameterSets - This is a set of communication/traffic pattern parameters indicating an anticipated communication schedule of all the ADN-AEs or ASN/MN-CSE hosted on the UE. The IN-CSE configures this parameter with the aggregated communication/traffic patterns of all ADN-AEs or ASN/MN-CSE hosted on the UE. The IN-CSE derives the aggregated communication/traffic patterns using the activityPatternElements attributes of the corresponding <AE> and <remoteCSE> resources. For a UE hosting one or more AEs, the IN-CSE uses the values provided in all the activityPatternElements attributes for the <AE>s hosted on this UE. For a UE hosting an ASN/MN-CSE, the IN-CSE uses the values provided by the activityPatternElements attribute of the <remoteCSE> resource. The IN-CSE shall configure the cpParameterSets as follows:
      • setId shall be assigned based on internal IN-CSE policies. This parameter will serve as a suggested name for the {apiRoot}/3gpp-cp-parameter-provisioning/v1/{scsAsId}/subscriptions/{subscriptionId}/cpSets/{setId} resource created by the SCEF. The SCEF may override this suggested name in which case, the SCEF will provide an updated value back in the response.
      • validityTime may be configured by the IN-CSE with an expiration time of the communication/traffic pattern of the UE. For example, the IN-CSE may configure this attribute with a value that is aligned with the expirationTime(s) of the corresponding <AE> or <remoteCSE> resource(s) associated with the ADN-AE(s) or ASN/MN-CSE hosted on the UE.
      • periodicCommunicationIndicator shall be set by the IN-CSE. If the activityPatternElements are configured with a repeating periodic communication pattern (e.g. detectable via the use of wildcards and/or step values in the activityPatternElements), then a PERIODICALLY enumerated value shall be used. Otherwise an ON_DEMAND enumerated value shall be used.
      • communicationDurationTime shall only be set by the IN-CSE if the periodicCommunicationIndicator is configured with a value PERIODICALLY. The IN-CSE shall configure this parameter with the time interval when the UE is actively communicating as specified within the activityPatternElements of the ADN-AE(s) or ASN/MN-CSE hosted on the UE. The value shall be expressed as a time duration in seconds.
      • periodicTime shall only be set by the IN-CSE if the periodicCommunicationIndicator is configured with a value PERIODICALLY. The IN-CSE shall configure this parameter with the duration of time separating active communication periods as specified within the activityPatternElements of the ADN-AE(s) or ASN/MN-CSE hosted on the UE. The value shall be expressed as a time duration in seconds.
      • scheduledCommunicationTime shall be set by the IN-CSE if the activityPatternElements of the ADN-AE(s) or ASN/MN-CSE specify certains days of the week and/or specific start and end times in the day that the UE actively communicates.
      • stationaryIndication and expectedUmts are not supported by the present document and shall not be included in the cpParameterSets
  • msisdn and externalGroupId are not supported by the present document and shall not be included.

Once a Communication Patterns Configuration has been created for a given UE, an IN-CSE shall keep it updated if/when any activityPatternElements for the ADN-AE(s) or ASN/MN-CSE hosted on a given UE are modified or deleted. To perform the update, the IN-CSE shall generate a Communication Patterns Configuration update request that contains the following information as specified in 3GPP TS 29.122 [4].

  • An HTTP PUT method shall be used
  • URI shall be set to {apiRoot}/3gpp-cp-parameter-provisioning/v1/{scsAsId}/subscriptions/{subscriptionId}/cpSets/{setId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} and {setId} segment are configured by the SCEF and returned to the IN-CSE in the Communication Patterns Configuration creation response.
  • The request payload shall include an updated CpInfo data structure as specified in 3GPP TS 29.122 [4]. The IN-CSE shall configure the CpInfo data structure based on the aggregated values of all the activityPatternElements of the ADN-AE(s) or ASN/MN-CSE that are hosted on the corresponding UE. The configuration of the individual CpInfo attributes shall follow the same rules as specified in the Communication Patterns Configuration create request above.

If/when all the activityPatternElements for the ADN-AE(s) or ASN/MN-CSE hosted on a given UE are deleted or contain communication schedules that have elapsed, the IN-CSE may generate a Communication Patterns Configuration delete request that contains the following information as specified in 3GPP TS 29.122 [4].

  • An HTTP DELETE method shall be used
  • URI shall be set to {apiRoot}/3gpp-cp-parameter-provisioning/v1/{scsAsId}/subscriptions/{subscriptionId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} segment is configured by the SCEF and returned to the IN-CSE in the Communication Patterns Configuration creation response.

Once a Communication Patterns Configuration for a given UE has been deleted, the IN-CSE can create a new Communication Patterns Configuration, using the same procedure described above, if/when an activityPatternElements for an ADN-AE or ASN/MN-CSE hosted on the UE is configured.

General Exceptions:

  • The SCEF is not reachable when IN-CSE tries to send Communication Patterns Configuration request. In this case the IN-CSE will not be able to configure the communication patterns of the UE in the underlying 3GPP network. Whether the IN-CSE continues to service requests for ADN-AE(s) or ASN/MN-CSE hosted on Ues that the IN-CSE is outside the scope of the present document.

Step 2: Communication Patterns Configuration Handling in the underlying 3GPP network

The underlying 3GPP network elements store the new/updated CP parameter set along with the associated SCEF id and validity time.

Step 3: SCEF sends Communication Patterns Configuration Response to IN-CSE

The SCEF authorizes the request and responds to acknowledge it accepted and processed the request.

A response to a Communication Patterns Configuration create request includes the following information:

  • If the result is successful, the SCEF will return a response code of 201 CREATED. If all communication/ traffic pattern parameters are not provisioned successfully, the SCEF will return a response code of 500 Internal Server Error which includes the report within the attribute cpReports with a list of failed setId (s) and the corresponding failure code (e.g. MALFUNCTION or OTHER_REASON) as specified in 3GPP TS29.122 [4]. In this case, the IN-CSE may retry the request. Alternatively, the IN-CSE may return a Response Status Code indicating "REQUESTED_ACTIVITY_PATTERN_NOT_PERMITTED" to the ADN-AE(s) or ASN/MN-CSE hosted on the UE. Then the ADN-AE(s) or ASN/MN-CSE hosted on the UE may retry their request with a different activityPatternElements attribute value.
  • The URI of the Communication Patterns Configuration subscription resource created by the SCEF. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-cp-parameter-provisioning/v1/{scsAsId}/subscriptions/{subscriptionId}. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies. The {subscriptionId} segment is configured by the SCEF.
  • The response payload will include a CpInfo data structure as specified in 3GPP TS 29.122 [4] that includes the attributes present in the request along with the following additional attributes:
    • self - a link to the Communication Patterns Configuration resource {apiRoot}/3gpp-cp-parameter-provisioning/v1/{scsAsId}/subscriptions/{subscriptionId}/cpSets/{setId}

A response to a Communication Patterns Configuration update request includes the following information:

  • If the result is successful, the SCEF will return a response code of 200 OK. If all communication/ traffic pattern parameters are not provisioned successfully, the SCEF will return one of the following response codes:
    • 409 Conflict which includes the report within the attribute cpReports with a list of failed setId(s) and the failure code "SET_ID_DUPLICATED" as specified in 3GPP TS29.122 [4]. In this case, the IN-CSE may return a Response Status Code indicating "REQUESTED_ACTIVITY_PATTERN_NOT_PERMITTED" to the ADN-AE(s) or ASN/MN-CSE hosted on the UE. Then the ADN-AE(s) or ASN/MN-CSE hosted on the UE may retry their request with a different activityPatternElements attribute value.
    • 500 Internal Server Error which includes the report within the attribute cpReports with a list of failed setId (s) and the corresponding failure code (e.g. MALFUNCTION or OTHER_REASON) as specified in 3GPP TS29.122 [4]. In this case, the IN-CSE may retry the request. Alternatively, the IN-CSE may return a Response Status Code indicating "REQUESTED_ACTIVITY_PATTERN_NOT_PERMITTED" to the ADN-AE(s) or ASN/MN-CSE hosted on the UE. Then the ADN-AE(s) or ASN/MN-CSE hosted on the UE may retry their request with a different activityPatternElements attribute value.
  • The response payload will include an updated CpInfo data structure as specified in 3GPP TS 29.122 [4]

A response to a Communication Patterns Configuration delete request includes the following information:

  • A response code of 204 NO CONTENT
  • The response will not contain a payload

See clause 8.3 for a list of possible error scenarios and error handling options for the IN-CSE.