Use Case: Policy Management SCEF Service Flows

The SCEF server establishes service flows between IoT devices and external functions that provide subscriber services. This use case is an overview of how the Policy Management system could implement a bicycle-sharing service, focusing on the role of the SCEF server in general terms and also in terms of Diameter message flow.

In this use case an individual bicycle is an IoT device (user equipment), and the person (subscriber) who wants to ride the bicycle has a mobile application. The service has four phases:
  1. Service exposure—The bicycle transmits its physical location
  2. Service configuration—The bicycle is configured for connectivity and is onboarded, and can then be displayed on a subscriber's mobile application
  3. Service start—The subscriber unlocks the bicycle using the mobile application, and then rides the bicycle to a destination
  4. Service end—The subscriber locks the bicycle at the destination

Service Exposure

The shared-bicycle business center uses a services capability server (SCS) to configure each bicycle, which is a NarrowBand IoT (NB-IoT) device, for location reporting. Once configured, each bicycle reports its physical location to a mobility management entity (MME). (This is a one-time operation.) One the bicycle's location is established, a subscriber's mobile application can display the bicycle's location by communicating with a home subscriber server (HSS). As illustrated in Figure 1, the following actions occur:

Service Exposure—Message Flow
  1. The SCS sends an onboarding Configuration on Monitoring Event (Location Reporting) request to the SCEF server.
  2. The SCEF server triggers a Diameter S6t Configuration Information Request (CIR) message to the HSS.
  3. The HSS sends a Diameter Configuration Information Authentication (CIA) response message to the SCEF server.
  4. The SCEF server sends a Configuration Confirmation message, indicating successful onboarding, to the SCS.
  5. The bicycle (NB-IoT device) reports its current location to the MME.
  6. The MME sends a Diameter T6a Reporting Information Request (RIR) message to the SCEF server to report the location of the NB-IoT device.
  7. The SCEF server authenticates the request and acknowledges the request to the MME.
  8. The SCEF server delivers the RIR message to the SCS.
  9. The SCS acknowledges the request to the SCEF server.

Service Configuration

The SCS configures the NB-IoT device for connectivity and triggers the SCEF server for onboarding. The NB-IoT device establishes a connection with the network for data exchange, using mobile terminated non-IP data delivery (MT-NIDD).

Service Configuration—Message Flow
  1. The SCS sends a T8 onboarding NIDD Configuration Request to the SCEF server.
  2. The SCEF server triggers a Diameter S6t NIDD Information Request (NIR) device authentication message to the HSS.
  3. The HSS sends a Diameter NIDD Information Authentication (NIA) response message to the SCEF server.
  4. The SCEF server sends an NIDD Configuration Confirmation message, indicating successful onboarding, to the SCS.
  5. The bicycle (NB-IoT device) sends an NIDD Connectivity Request to the MME.
  6. The MME sends a Diameter T6a Connection Management Request (CMR) message to the SCEF server.
  7. The SCEF server identifies the NB-IoT device as valid, authenticates the request, and acknowledges the request with a Diameter Connection Management Answer (CMA) message to the MME.

Service Start

Using the mobile application, the subscriber obtains the NB-IoT device location information from the HSS and goes to the bicycle. The subscriber uses the mobile application to trigger the SCS to unlock the bicycle using mobile terminated non-IP data delivery (MT-NIDD). (Unlocking is a routine and repeated operation.) As illustrated in Figure 2, the following actions occur:

Service Start—Message Flow
  1. The mobile application uses the NIDD connection to send mobile-terminated (MT) downlink data to the SCS.
  2. The SCS sends a request (NTR) message with the data to the SCEF server.
  3. The SCEF server sends an acknowledgment (NTA) message to the SCS.
  4. The SCEF sends a Diameter T6b MT Data Request (TDR) message with the data to the MME.
  5. The MME sends mobile-terminated (MT) downlink data to the NB-IoT device.
  6. The MME sends an acknowledgment (TDA) message to the SCEF server.

Service End

The subscriber rides the bicycle to a destination and manually locks the bicycle. (Locking is a routine and repeated operation.) The NB-IoT device establishes a connection with the network for data exchange, using mobile originated non-IP data delivery (MO-NIDD), to report the updated lock status. As illustrated in Figure 4, the following actions occur:

Service End—Message Flow
  1. The NB-IoT device uses the NIDD connection to send mobile-originated (MO) uplink data to the MME.
  2. The MME sends a Diameter T6a MO Data Request (ODR) message with the data to the SCEF server.
  3. The SCEF server identifies the NB-IoT device as valid, authenticates the request, and delivers the data to the SCS.
  4. The SCEF server sends a Diameter response to the MME indicating successful data delivery.
Parent topic: Introduction