Skip to content

7.9 Setting up an AS session with required QoS procedure

7.9.1 Overview

3GPP supports setting up an IP flow to a UE with a specific QoS (e.g. low latency or jitter) and priority handling by 3rd party service providers (AS/SCS session) via the T8 API. The oneM2M system may use this functionality for the communication management between an IN-CSE and a UE. An AE may specify, for a set of target resources, a QoS level parameter which refers to the pre-defined QoS information between the oneM2M and the underlying 3GPP network. Based on this information, the oneM2M system shall map the operation addressing those resources from the IN-CSE to the target UE to the 3GPP IP flow, negotiate the QoS with the underlying 3GPP network, and request the underlying 3GPP network to deliver the operation with the negotiated QoS.

7.9.2 Resource Structure

Refer to the clause 9.6.63 Resource Type <e2eQosSession> of oneM2M TS-0001[1].

7.9.3 Procedures

7.9.3.1 Create/Update E2E QoS procedure

Figure 7.9.3.1-1: Create/Update E2E QoS procedure

Figure 7.9.3.1-1: Create/Update E2E QoS procedure

Step 0: The IN-AE, ADN-AE or ASN/MN-CSE performs oneM2M registration. The IN-CSE is pre-provisioned with 3GPP QoS Information based on a SLA with the MNO.

The IN-AE, ADN-AE or ASN/MN-CSE performs the oneM2M registration procedure. Then the IN-CSE gets the pointOfAccess network registration information of ASN/MN-CSE or ADN-AE.

The IN-CSE uses the pre-provisioned 3GPP QoS information to translate oneM2M QoS parameters defined in <e2eQosSession> resources into the QoS parameters defined by the MNO and used over the SCEF T8 interface.

Step 1: An AE or CSE sends a <e2eQosSession> CREATE/UPDATE request to the IN-CSE.

The <e2eQosSession> CREATE/UPDATE request includes the following information:

  • To parameter shall be configured with the Resource-ID of an <AE>, <remoteCSE> or <CSEBase> resource hosted by the IN-CSE
  • From parameter shall be configured with the AE-ID or CSE-ID of the Originator

Note

The Originator of the <e2eQosSession> CREATE/UPDATE request may be an entity specified in the sessionEndpoints attribute. Alternatively, it may be a different entity.

  • sessionEndpoints attribute shall be set to a list consisting of one or more AE-IDs and/or CSE-IDs representing the endpoints of the E2E QoS session.
  • e2eQosRequirements attribute shall be configured with a list of one or more tuples. Each tuple in the list has the following elements:
    • qosLevel element shall be set to a value between 0 and 100.
    • resourceIDList element shall beset to a list of resource identifiers the QoS requirement applies to.
    • sessionSchedule element may be set. If set, it consists of seven fields of second, minute, hour, day of month, month, day of week and year.
    • numOfRequests element may be set. If set, it consists of the minimum number of requests required to be transferred at the specified qosLevel.
    • numOfBytes element may be set. If set, it consists of the minimum number of bytes required to be transferred at the specified qosLevel.
  • e2eQosPolicies attribute may be set. If set, it is configured with 1 or more tuples. Each tuple has the following elements:
    • status element shall be set with a value of FAILED, DISABLED or USAGE_EXHAUSTED
    • action element shall be set with a value of RE-ENABLE or DISABLE

Step 2: The IN-CSE validates the E2E QoS session endpoint entities.

The IN-CSE receives and validates the <e2eQosSession> CREATE/UPDATE request. The IN-CSE validates the sessionEndpoints attribute. The IN-CSE performs this check by first confirming that each AE-ID and/or CSE-ID configured within the sessionEndpoints attribute matches an AE-ID and CSE-ID of one of its Registree AEs or CSEs.

The IN-CSE also checks that at least one tuple is configured in the e2eQosRequirements attribute and that the qosLevel element and resourceIDList in this tuple is configured. The IN-CSE also checks that all other mandatory attributes and parameters in the request are present and their values comply with their supported data types. The IN-CSE also checks that the values of all other optional attributes and parameters in the request comply with their supported data types and are properly formatted. If these checks are successful, the IN-CSE creates/updates the <e2eQosSession> according to the request. Then the IN-CSE proceeds to Step 3. Otherwise, the IN-CSE proceeds to Step 6 and returns a Response Status Code indicating BAD_REQUEST error.

Step 3: If necessary, the IN-CSE triggers the E2E QoS session endpoint entities.

If entities specified in the sessionEndpoints attribute are registered to the IN-CSE and use an underlying 3GPP network, the IN-CSE checks the connection (e.g. TCP) with the sessionEndpoints. If the sessionEndpoints do not have an active 3GPP PDN connection to the IN-CSE (i.e. ASN/MN-CSE or ADN-AE pointOfAccess information is not configured or IN-CSE detects failed communication with ASN/MN-CSE or ADN-AE when the connection is based on TCP), the IN-CSE should send a device trigger request to the corresponding ASN/MN-CSE or ADN-AE to have it establish a connection (e.g. based on TCP) to the IN-CSE.

Note

If the sessionSchedule element is configured, the IN-CSE shall use the schedule information to determine whether to perform this step during the processing of the <e2eQosSession> CREATE/UPDATE request or sometime thereafter (e.g. closer to the time when scheduled communication via the session is required).

Step 4: The IN- CSE sends QoS Session Subscription Request(s) to the SCEF.

For each QoS session endpoint that connects to the IN-CSE via an underlying 3GPP network connection and that has an active PDN connection, the IN-CSE sends a AsSessionWithQoSSubscription Request to the SCEF.

Note

If the sessionSchedule element is configured, the IN-CSE shall use the schedule information to determine whether to perform this step during the processing of the <e2eQosSession> CREATE/UPDATE request or sometime thereafter (e.g. closer to the time when scheduled communication via the session is required).

Each AsSessionWithQoSSubscription Request from the IN-CSE to the SCEF contains information as specified in 3GPP TS 29.122 [4]. Such information includes:

  • An HTTP POST method shall be used
  • URI shall be set to {apiRoot}/3gpp-as-session-with-qos/v1/{scsAsId}/subscriptions/. The {apiRoot} and {scsAsId} segments are configured based on Service Provider and MNO policies.
  • The request payload includes an AsSessionWithQoSSubscription data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
    • supportedFeatures shall be set to a string value of "0" indicating the IN-CSE does not support the QoS Session negotiable features specified in 3GPP TS 29.122 [4].
    • notificationDestination shall be set to a URI that the SCEF should target QoS session related notifications towards. The value of this URI shall be based on internal IN-CSE policies.
    • flowInfo includes the following attributes:
      • flowId shall be set to a integer value that describes the IP flow. A value is assigned by the IN-CSE according local policy. The value that is used is unique within the scope of the IN-CSE.
      • flowDescriptions shall be an array of strings configured with two entries. The first entry in the array is an IP flow description for oneM2M requests and responses flowing from the IN-CSE to the QoS session endpoint applicable to this request. The second entry in the array is an IP flow description for oneM2M requests and responses flowing in the reverse direction from the QoS session endpoint to the IN-CSE.
        • Entry #1 in the flowDescriptions array includes the following attributes:
          • direction shall be set to a value of "out"
          • sourceIP address shall be set to the IP address of the IN-CSE and destination IP address is set to the IP addresses configured in the pointOfAccess attribute of the <AE> or <remoteCSE> resource hosted on the IN-CSE and associated with the QoS session endpoint applicable to this request.
          • protocol: shall be set to a value of "TCP" or "UDP" based on the underlying transport configured in the pointOfAccess attribute of the <AE> or <remoteCSE> resource hosted on the IN-CSE and associated with the QoS session endpoint applicable to this request. For example, "TCP" is set if the protocol configured in the pointOfAccess is HTTP, MQTT or WebSocket. "UDP" is set if the protocol configured is CoAP.
          • source port shall be set to the port of the IN-CSE and destination port is set to the port configured in the pointOfAccess attribute of the <AE> or <remoteCSE> resource hosted on the IN-CSE and associated with the QoS session endpoint applicable to this request.
        • Entry #2 in the flowDescriptions array includes the following attributes:
          • direction shall be set to a value of "in"
          • sourceIP address shall be set to the IP address configured in the pointOfAccess attribute of the <AE> or_<remoteCSE> resource hosted on the IN-CSE and associated with the QoS session endpoint applicable to this request and destination IP address is set to the IP address of the IN-CSE.

Note

The order is reversed from the order used in Entry #1.

    -  _protocol_: shall be set to a value of "TCP" or "UDP" based on the underlying transport configured in the _pointOfAccess_ attribute of the &lt;_AE_> or &lt;_remoteCSE_> resource hosted on the IN-CSE and associated with the QoS session endpoint applicable to this request. For example, "TCP" is set if the protocol configured in the _pointOfAccess_ is HTTP, MQTT or WebSocket. "UDP" is set if the protocol configured is CoAP.
    -  _source port_ shall be set to the port configured in the _pointOfAccess_ attribute of the &lt;_AE_> or &lt;_remoteCSE_> resource hosted on the IN-CSE and associated with the QoS session endpoint applicable to this request and _destination port_ is set to the port of the IN-CSE.

Note

The order is reversed from the order used in Entry #1.

  • qosReference shall be set to a pre-provisioned string value that maps to the qosLevel. This mapping is based on a SLA with the MNO. The qosReference serves as an identifier of the pre-defined QoS information pre-provisioned into the IN-CSE based on a SLA with the MNO.
  • ueIpv4Addr shall be set to the IPv4 address (if applicable) configured in the pointOfAccess attribute of the <AE> or <remoteCSE> resource hosted on the IN-CSE and associated with the QoS session endpoint applicable to this request.
  • ueIpv6Addr shall be set to the IPv6 address (if applicable) configured in the pointOfAccess attribute of the <AE> or <remoteCSE> resource hosted on the IN-CSE and associated with the QoS session endpoint applicable to this request.
  • usageThreshold includes the following attributes:
    • duration shall be set to the amount of time in seconds that the QoS session is requested to remain active. The IN-CSE computes this duration by inspecting all of the <e2eQosSession> resources that it hosts and that have a session endpoint that matches the session endpoint applicable to this request. For any matches found, the IN-CSE will aggregate the sessionSchedule elements (if any) configured within the list of e2eQosRequirements tuples of these <e2eQosSession> resources. Based on the aggregated sessionSchedule elements and local policies, the IN-CSE will determine a duration of time to request. If no sessionSchedule elements are configured, the IN-CSE will base its determination solely on local policies.
    • totalVolume shall be set to a total number of bytes of data that are required to be exchanged between the IN-CSE and the session endpoint applicable to this request. The IN-CSE shall compute this number of bytes by inspecting all of the <e2eQosSession> resources that it hosts and that have a session endpoint that matches the session endpoint applicable to this request. For any matches found, the IN-CSE will sum all of the numOfBytes elements (if any) configured within the list of e2eQosRequirements tuples of these <e2eQosSession> resources. Based on the numOfBytes elements and local policies, the IN-CSE will determine an amount to request. If no numOfBytes elements are configured, the IN-CSE will base its determination solely on local policies.
  • sponsorInfo may be set. If set, the value is a string based on a SLA with the MNO.
  • ethFlowInfo,macAddr,requestTestNotification and websockNotifConfig are not supported by the present document and are not included.

Step 5: SCEF sends QoS Session Response (s) to IN-CSE.

The SCEF handles the AsSessionWithQoSSubscription Request together with the3GPP network entities. The SCEF sends an AsSessionWithQoSSubscription Response that contains information as specified in 3GPP TS 29.122 [4] to the IN-CSE.

The message includes the following information.

  • A response code of 201 CREATED
  • The URI of the QoS Session Subscription resource created by the SCEF. The URI is returned in the HTTP Location header with a format of {apiRoot}/3gpp-as-session-with-qos/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 may include a AsSessionWithQoSSubscription 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 is configured with a URI to the resource created by the SCEF for the request

General Exceptions:

  • If the SCEF responds with one of the error response codes defined in clause 8.3, the IN-CSE shall update the e2eQosStatus of the <e2eQosSession> resource to a value of FAILED.

Step 6: The IN-CSE returns response to Originator.

7.9.3.2 QoS Session request processing procedure

Figure 7.9.3.2-1: Setting up 3GPP session with required QoS

Figure 7.9.3.2-1: Setting up 3GPP session with required QoS

Step 0: <e2eQosSession> created and IN-CSE creates QoS Session Subscription to SCEF

Step 1: The IN-AE sends a request that targets a E2E QoS session endpoint (e.g. ASN/MN-CSE)

The IN-AE sends a request to the IN-CSE that targets an entity that is configured as an E2E QoS session endpoint within a <e2eQosSession> resource hosted by the IN-CSE.

Step 2: The IN- CSE receives and processes the request and checks <e2eQosSession> resources

The IN-CSE processes the received request and obtains the targeted end point from the To parameter. Then IN-CSE checks the targeted end point and From parameters to see if they match with any sessionEndpoints configured within the <e2eQosSession> resources hosted by the IN-CSE. If a match is found, the IN-CSE then checks the To parameter in the request to see if the specified resource identifier matches any resource identifiers in the resourceIDList element of the e2eQosRequirements attribute configured within the same <e2eQosSession> resource. If the IN-CSE does not find a <e2eQosSession> resource with matching session endpoints or a matching resource identifier, the IN-CSE shall attempt to forward the request to the targeted endpoint without any negotiated 3GPP QoS and proceed to Step 7. If a match is found, the IN-CSE shall checks the e2eQosStatus attribute of the matching <e2eQosSession> resource to determine whether the QoS session is enabled or not.

The IN-CSE also checks whether the entity targeted by the request has an active 3GPP PDN connection and is reachable by the IN-CSE.

  • CASE A: The QoS session is enabled and the targeted entity has an active 3GPP PDN connection. The IN-CSE proceeds to Step 6.
  • CASE B: The targeted entity has an inactive 3GPP PDN connection (i.e. ASN/MN-CSE or ADN-AE pointOfAccess information is not configured or IN-CSE detects failed communication with ASN/MN-CSE or ADN-AE) then the IN-CSE proceeds to Step 3.
  • CASE C: The targeted entity has an active 3GPP PDN connection (i.e. ASN/MN-CSE or ADN-AE pointOfAccess information is configured), but the QoS session has been disabled (e2eQosStatus attribute is set to DISABLED or USAGE_EXHAUSTED). The IN-CSE proceeds to Step 4.

Step 3: The IN-CSE triggers the targeted E2E QoS session endpoint entity.

The targeted entity is registered to the IN-CSE and uses an underlying 3GPP network, but does not have an active 3GPP PDN connection to the IN-CSE, the IN-CSE sends a device trigger request to the entity to have it establish a 3GPP PDN connection to the IN-CSE. The IN-CSE then checks whether the QoS session is enabled or not. If the QoS session has been disabled (e2eQosStatus attribute is set to DISABLED or USAGE_EXHAUSTED) the IN-CSE proceeds to Step 4, otherwise Step 6.

Step 4: The IN-CSE sends a request to update the QoS Session Subscription to re-enable the QoS session

If the configured e2eQosRequirements permit the IN-CSE to request that the QoS session be re-enabled when the e2eQosStatus attribute is set to DISABLED or USAGE_EXHAUSTED, the IN-CSE may execute this step. Otherwise, the IN-CSE shall either choose to continue processing the request in a best-effort fashion or go to Step 7 with a corresponding ResponseStatusCode indicating "NETWORK_QOS_CONFIG_ERROR" by local policy.

For each QoS session endpoint that connects to the IN-CSE via an underlying 3GPP network connection and that has an active PDN connection, the IN-CSE sends a AsSessionWithQoSSubscription Request to the SCEF.

The IN-CSE sends a request to update to AsSessionWithQoSSubscription Request from the IN-CSE to the SCEF contains information as specified in 3GPP TS 29.122 [4]. Such information includes:

  • An HTTP PUT method shall be used
  • URI shall be set to {apiRoot}/3gpp-as-session-with-qos/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 request payload includes an AsSessionWithQoSSubscription data structure as specified in 3GPP TS 29.122 [4] with the following attributes:
    • supportedFeatures shall be set to a string value of "0" indicating the IN-CSE does not support the QoS Session negotiable features specified in 3GPP TS 29.122 [4].
    • notificationDestination shall be set to a URI that the SCEF should target QoS session related notifications towards. The value of this URI shall be based on internal IN-CSE policies.
    • flowInfo includes the following attributes:
      • flowId shall be set to a integer value that describes the IP flow. A value is assigned by the IN-CSE according local policy. The value that is used is unique within the scope of the IN-CSE.
      • flowDescriptions shall be an array of strings configured with two entries. The first entry in the array is an IP flow description for oneM2M requests and responses flowing from the IN-CSE to the QoS session endpoint applicable to this request. The second entry in the array is an IP flow description for oneM2M requests and responses flowing in the reverse direction from the QoS session endpoint to the IN-CSE.
        • Entry #1 in the flowDescriptions array includes the following attributes:
          • direction shall be set to a value of_"_ out"
          • sourceIP address shall be set to the IP address of the IN-CSE and destination IP address is set to the IP addresses configured in the pointOfAccess attribute of the <AE> or <remoteCSE> resource hosted on the IN-CSE and associated with the QoS session endpoint applicable to this request.
          • protocol: shall be set to a value of " TCP" or "UDP" based on the underlying transport configured in the pointOfAccess attribute of the <AE> or <remoteCSE> resource hosted on the IN-CSE and associated with the QoS session endpoint applicable to this request. For example, "TCP" is set if the protocol configured in the pointOfAccess is HTTP, MQTT or WebSocket. "UDP" is set if the protocol configured is CoAP.
          • source port shall be set to the port of the IN-CSE and destination port is set to the port configured in the pointOfAccess attribute of the <AE> or <remoteCSE> resource hosted on the IN-CSE and associated with the QoS session endpoint applicable to this request.
        • Entry #2 in the flowDescriptions array includes the following attributes:
          • direction shall be set to a value of "in"
          • sourceIP address shall be set to the IP address configured in the pointOfAccess attribute of the <AE> or <remoteCSE> resource hosted on the IN-CSE and associated with the QoS session endpoint applicable to this request and destination IP address shall be set to the IP address of the IN-CSE.

Note

The order is reversed from the order used in Entry #1.

        - _protocol_: shall be set to a value of "TCP" or "UDP" based on the underlying transport configured in the _pointOfAccess_ attribute of the &lt;_AE_> or &lt;_remoteCSE_> resource hosted on the IN-CSE and associated with the QoS session endpoint applicable to this request. For example, "TCP" is set if the protocol configured in the _pointOfAccess_ is HTTP, MQTT or WebSocket. "UDP" is set if the protocol configured is CoAP.
        - _source port_ shall be set to the port configured in the _pointOfAccess_ attribute of the &lt;_AE_> or &lt;_remoteCSE_> resource hosted on the IN-CSE and associated with the QoS session endpoint applicable to this request and _destination port_ is set to the port of the IN-CSE.

Note

The order is reversed from the order used in Entry #1.

  • qosReference shall be set to a pre-provisioned string value that maps to the qosLevel. This mapping is based on a SLA with the MNO. The qosReference serves as an identifier of the pre-defined QoS information pre-provisioned into the IN-CSE based on a SLA with the MNO.
  • ueIpv4Addr shall be set to the IPv4 address (if applicable) configured in the pointOfAccess attribute of the <AE> or <remoteCSE> resource hosted on the IN-CSE and associated with the QoS session endpoint applicable to this request.
  • ueIpv6Addr shall be set to the IPv6 address (if applicable) configured in the pointOfAccess attribute of the <AE> or <remoteCSE> resource hosted on the IN-CSE and associated with the QoS session endpoint applicable to this request.
  • usageThreshold includes the following attributes:
    • duration shall be set to the amount of time in seconds that the QoS session is requested to remain active. The IN-CSE computes this duration by inspecting all of the <e2eQosSession> resources that it hosts and that have a session endpoint that matches the session endpoint applicable to this request. For any matches found, the IN-CSE will aggregate the sessionSchedule elements (if any) configured within the list of e2eQosRequirements tuples of these <e2eQosSession> resources. Based on the aggregated sessionSchedule elements and local policies, the IN-CSE will determine a duration of time to request. If no sessionSchedule elements are configured, the IN-CSE will base its determination solely on local policies.
    • totalVolume shall be set to a total number of bytes of data that are required to be exchanged between the IN-CSE and the session endpoint applicable to this request. The IN-CSE shall compute this number of bytes by inspecting all of the <e2eQosSession> resources that it hosts and that have a session endpoint that matches the session endpoint applicable to this request. For any matches found, the IN-CSE will sum all of the numOfBytes elements (if any) configured within the list of e2eQosRequirements tuples of these <e2eQosSession> resources. Based on the numOfBytes elements and local policies, the IN-CSE will determine an amount to request. If no numOfBytes elements are configured, the IN-CSE will base its determination solely on local policies.
  • sponsorInfo may be set. If set, the value is a string based on a SLA with the MNO.
  • ethFlowInfo, macAddr, requestTestNotification and websockNotifConfig are not supported by the present document and are not included.

Step 5: SCEF sends QoS Session Response(s) to IN-CSE .

The SCEF handles the AsSessionWithQoSSubscription Request together with the 3GPP network entities. The SCEF sends an AsSessionWithQoSSubscription Response that contains information as specified in 3GPP TS 29.122 [4] to the IN-CSE.

The message includes the following information.

  • A response code of 200 OK
  • The response payload will include a AsSessionWithQoSSubscription 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 is configured with a URI to the resource created by the SCEF for the request.

General Exceptions:

If the SCEF responds with one of the error response codes defined in clause 8.3, the IN-CSE shall update the e2eQosStatus attribute of the <e2eQosSession> resource to a value of FAILED.

Step 6: The IN-CSE delivers the message with the required QoS and updates the <e2eQosSession> resource.

If the QoS session is enabled, the IN-CSE forwards the request to the targeted session endpoint entity. After receiving a response back from the targeted session endpoint, the IN-CSE updates the e2eQosStatus attribute of the <e2eQosSession> resource and prepares a response for the Originator (IN-AE).

If the QoS session is disabled and the IN-CSE is un-successful in re-enabling it, then the IN-CSE shall either choose to continue processing the request in a best-effort fashion or go to Step 7 with a corresponding ResponseStatusCode indicating "NETWORK_QOS_CONFIG_ERROR" by local policy.

Step 7: The IN-CSE returns response to Originator.

IN-CSE sends response to the IN-AE.

7.9.3.3 3GPP QoS status monitoring and report procedure

Figure 7.9.3.3-1: 3GPP QoS status report procedure

Figure 7.9.3.3-1 : 3GPP QoS status report procedure

Step 1: The 3GPP network entities detect a bearer level event.

The 3GPP entities may notify the SCEF about bearer level events for the Rx session (e.g. transmission resources are released/lost) with an IP-CAN Session Modification as described in 3GPP TS 23.203 [11].

Step 2: SCEF sends Status notification message to IN-CSE.

When the SCEF receives information of a status change in step 1, the SCEF creates and sends an Event Notification message to the IN-CSE as specified in 3GPP TS 29.122 [4].

The Event Notification request includes the following:

  • event indicates the event reported by the SCEF and is configured with one of the following enumerated values as specified in 3GPP TS 29.122 [4]
    • SESSION_TERMINATION, LOSS_OF_BEARER, RECOVERY_OF_BEARER, RELEASE_OF_BEARER, USAGE_REPORT.
  • accumulatedUsage indicates the amount of time in seconds that the QoS session was used and the amount of data bytes transferred via the QoS session when event is USAGE_REPORT. This notification is sent when the usage exceeds the values defined in the usageThreshold configured in the AsSessionWithQoSSubscription.
  • flowIds is configured with the same value of flowId in the AsSessionWithQoSSubscription.

Step 3: IN-CSE performs the action according to the status

When the IN-CSE receives the Event Notification, the IN-CSE will map the event and accumulatedUsage to the e2eQosStatus of <e2eQosSession> resource and performs the action according to the status.

3GPP event oneM2M QoS session status (e2eQosStatus)
SESSION_TERMINATION DISABLED
LOSS_OF_BEARER DISABLED
RELEASE_OF_BEARER DISABLED
RECOVERY_OF_BEARER ENABLED
USAGE_REPORT ENABLED (if accumaltedUsage indicates duration/volume has not been exhausted)
USAGE_EXHAUSTED (if accumaltedUsage indicates duration/volume has been exhausted)

The IN-CSE may update the e2eQosStatus of the resource <e2eQosSession> resource if there is no Step 4.

Step 4 (Optional): IN-CSE request s to delete QoS Session.

If the e2eQosPolicies attribute of the <e2eQosSession> resource is configured, then the IN-CSE evaluates and performs the configured action(s).

For example, if the configured action is DELETE when status equals DISABLED, then the IN-CSE will delete any existing QoS Session Subscription(s) to the underlying 3GPP network and also delete the <e2eQosSession> resource.

An IN-AE may also issue a request to delete an <e2eQosSession> resource. When the IN-CSE receives this request, it will delete any existing QoS Session Subscription(s) to the underlying 3GPP network and also delete the <e2eQosSession> resource.

Step 5 (Optional): IN-CSE sends delete request(s) for any existing QoS Session Subscription(s) to the underlying 3GPP network

The IN-CSE sends a DELETE request targeting the URI of the subscription resource corresponding to this AsSessionWithQoSSubscription.

For each QoS session subscription associated with the <e2eQosSession> resource being deleted, the IN-CSE sends a AsSessionWithQoSSubscription DELETE Request to the SCEF. The request to delete a AsSessionWithQoSSubscription contains information as specified in 3GPP TS 29.122 [4]. Such information includes:

  • An HTTP DELETE method is used
  • URI shall be set to {apiRoot}/3gpp-as-session-with-qos/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.

Step 6 (Optional): SCEF sends QoS Session Response (s) to IN-CSE.

The SCEF handles the AsSessionWithQoSSubscription DELETE Request together with the 3GPP network entities. The SCEF sends an AsSessionWithQoSSubscription DELETE Response that contains information as specified in 3GPP TS 29.122 [4] to the IN-CSE.

The message includes the following information.

  • A response code of 204 No Content

If the IN-CSE receives a 204 No Content response code from the SCEF, it deletes the <e2eQosSession> resource. Otherwise, the IN-CSE does not delete the <e2eQosSession> resource.

Step 7 (Optional): IN-CSE returns response to IN-AE.

The IN-CSE sends a DELETE response back to the IN-AE.