1. Edge and Fog Computing Group Name: TP
Source: Kenichi Yamamoto(KDDI), Catalina Mladin (Convida)
Meeting Date:
Agenda Item: WI-0015 Use Cases Collection, WI-0046 Vehicular Domain Enablement, WI-0028 Industrial Domain Enablement

2. Background (1)
In IT, “Cloud” encompasses one or more nodes (e.g. Data Centers) that providing a set of functions hosted remotely - specifically in an IP network, or in general, on the Internet.
“Cloud computing” refers to the provisioning of compute resources on a cloud node or a server that is located in the Internet. These resources include hardware and software resources, storage, communications, analytics, etc.
Main benefit: ease of service deployment and provisioning.

3. Background (2)
In some large and distributed systems like those supporting IoT, direct interaction with the end sensors puts undue burdens on the cloud nodes and increase communication latency.
“Edge nodes”
Have cloud-like functions but are much closer to the edge where data is generated.
Have cloud-like capabilities i.e. compute, storage, communication, etc. enabling deployment of services and applications at the edge of networks
Coexist and communicate with the cloud

4. Background (3) Fog = small cloud on the ground. “Fog nodes” (fogs) *
“..are intermediary compute elements of the smart end-devices access network that are situated between the Cloud and the smart end-devices. […] may be either physical or virtual elements and are tightly coupled with the smart end-devices or access networks. […] typically provide some form of data management and communication service […] can be federated to provide horizontal expansion of the functionality over disperse geolocations.” *
Vertically, form a hierarchy of fog levels between cloud and end devices, meeting the service needs of sparsely deployed devices.
* based on NIST Special Publication definition

5. Edge and Fog in IoT Deploying Edge and Fog Nodes in M2M System
Reduces communication cost.
Mitigates workload of data center.
Provides low latency services.
Provides redundancy and improves reliability
etc.
Edge and Fog are often used interchangeably and it is unclear right now if these differences matter to oneM2M, but …

6. One view on differences*
Mobility:
Fog assumes mobility inherently. For Edge the term MEC (Mobile Edge Computing) provides that emphasis.
Applications:
Fog focuses on gateway devices. MEC focuses on external applications e.g. traffic control, autonomous vehicles, augmented reality.
Data processing
Fog processing closer to the local area networks, MEC pushes this even closer to the source.
Tenancy:
Fog addresses single-tenant, enterprise-owned set of devices, MEC multi-tenant applications, will be prioritized for multiple stakeholders.
* From material presented at MEC Congress

7. Related Organizations
ETSI ISG MEC(Multi-access Edge Computing)
ETSI GS MEC 002(Technical Requirements) contains
Use cases and requirements of Edge computing.
5GAA(5G Automotive Association)
White paper(Toward fully connected vehicles) shows
V2X use cases by Edge Computing.
Collaboration between 3GPP and ETSI ISG MEC and 5GAA.
OpenFog Consortium:
EdgeX Foundry:
Edge Computing Consortium:
IEEE P1934
NIST

8. oneM2M and Edge/Fog Computing

9. Example Edge Node mapping to oneM2M Architecture
Applications
Infrastructure Node(IN)
IN-AE
Servers
Mca
IN-CSE
Infrastructure Domain
Underlining Network
Field Domain
Middle Node(MN)
Mcc
MN-AE
Mca
Edge Node
MN-CSE
Underlining Network
Mcc
Mcc
Application Service Node(ASN)
Middle Node(MN)
ASN-AE
MN-AE
Mca
Mca
Communication Module GW
ASN-CSE
MN-CSE
Mca
Infortainment
Non oneM2M interface
Non oneM2M interface
In-vehicle
network
Non-oneM2M Device Node
(No DN)
Application Dedicated Node
(ADN)
ECU
ECU

10. Example Edge/Fog Deployment
Cloud/Data Center
Central
Servers
Application
Servers
Application
Provider
IN-AE
IN-CSE
FFS: how Edge/Fog differences affect M2M architecture
Edge/ Fog Network
Edge/Fog
Node
MN-AE
Edge/Fog
Node
MN-CSE
Local Network
Mobile Base Station
Mobile Base Station
ASN-AE
MN-AE
ASN-CSE
MN-CSE
Hospital
Surveillance
Camera
Factory
Factory

11. Potential oneM2M topics/ issues
Differences between Edge and Fog deployments for the oneM2M system architecture and deployments.
Identify explicit use cases and gaps.
Study already identified issues:
OpenFog identifies functionality needed for fog computing, namely, compute, storage, communication, and analytics. They also identify the need for communication between fog nodes, and between fog and cloud nodes. Does oneM2M have the procedures needed for communication between fog nodes?
ETSI MEC has looked at service migration and service-aware routing between Edge nodes. Should oneM2M support this?
IETF has introduced the concept of pools. Does oneM2M enable the use of fog nodes within pools?
All identify management of the fog nodes (SL(Service Layer) management rather than device management) as issue.

12. Use Cases

13. Use Case for Vehicles - Accident Notification Service -
Data Center
Central
Servers
Application
Servers
Application
Provider
5. Edge/Fog Node A gets the appropriate Edge/Fog Node information from Application Servers in order to provide the accident information.
Edge/ Fog Network
Server Pool
Edge/Fog
Node A
7. Edge/Fog Node B analyzes network bandwidth of each vehicles near the accident site, and sends the appropriate video clip(high or low quality) to vehicles
4. Edge/Fog Node A processes the video clips. If Node A’s video processing capability is not enough or does not work properly, pool-based capability sharing/scaling with other nearby Edge/Fog Nodes can be utilized.
Edge/Fog
Node B
Edge/Fog Node C
Data
Data
Edge/Fog
Node D
6. Sending the video clips with accident information to Edge/Fog Node B.
Data
Local Network
Data
Data
Mobile Base Station
RSU
3. Sending the video clips with location data to Edge/Fog Node via RSU.
Data
Data
Surveillance
Camera
Data
Data
Data
8. The Vehicles receive the video clip.
Each driver know accident by in-vehicle infotainment/3D map and decide the appropriate direction.
2. Vehicular on-board cameras/sensors and surveillance cameras near the accident site recognize the accident, and record video
Data
1. A vehicular accident happens

14. Use Case for Vehicles - Generating near real-time 3D Maps -
Data Center
Central
Servers
Application
Servers
Application
Provider
3. Edge/Fog Node A sends following data to Application Servers and Edge/Fog Node B.
Categorized data(e.g. high priority events)
Differential data of 3D maps. 3
4a. Application Servers incorporate the differential map data of into existing 3D map, and store as master data.
Data
Edge/ Fog Network
4. Edge/Fog Node B incorporates the differential map data of into existing 3D map.
3. Edge/Fog Node A processes as follow.
Aggregates data from vehicles(e.g. removing redundant data)
Categorizes data(high priority events(e.g. traffic accidents), low priority events)
Updates 3D maps of the Node A’s areas.
Abstracts differential data of 3D maps
Edge/Fog
Node B
Data
Edge/Fog
Node A
5. Edge/Fog Node B sends the updated 3D maps and the categorized data.
Data
Data
Data
Local Network
Data
Mobile Base Station
RSU
Data
Data
Data
Data
Data
Data
6. Each vehicle updates in-vehicle 3D maps using the updated 3D map and the categorized data.
7. Each driver knows events(e.g. traffic accident) by the 3D map and moves appropriate direction.
Data
Data
1. Vehicles collects surrounding data from vehicular sensors(e.g. video camera, radar, LIDAR, …).
2. Vehicles send those data to Edge/Fog node via RSU.

15. Use Case for Healthcare - Health monitoring service -
Data Center
Central
Servers
Application
Servers
Application
Provider
5. Edge/Fog Node B gets additional data(e.g. route to Hospital A) from Edge/Fog Node A and process to provide the information for user A
Data
3. Edge/Fog Node B sends the data of blood pressure to Application Servers.
4. Application Servers analyze the data and send neighborhood hospital information(Hospital A).
Data
Edge/ Fog Network
Edge/Fog
Node B
Edge/Fog
Node A
Data
2. Edge/Fog Node B detects that blood pressure value of user A is high.
6. Edge/Fog Node B sends the aggregate data(e.g. route to Hospital A, blood pressure value) to user A.
Local Network
1. User A subscribes a healthcare service.
He puts on health sensors (e.g. blood pressure, temperature, blood sugar).
The sensor data are sent to neighborhood Edge/Fog Node every 10 minutes via his smartphone.
Mobile Base Station
Mobile Base Station
Data
Hospital A
Data
User A
7. He receives the data by his smartphone, and understands his health condition.
He tries to go to Hospital A by the route information from Edge/Fog Node B.
8. He arrives to the Hospital A, and consults a doctor.

16. Use Case for Industry - Factory automation -
Data Center
Central
Servers
Application
Servers
Application
Provider
4. Application Servers store and analyze the data, then send a recovery method to Edge/Fog Node B.
Data
3. Edge/Fog Node B analyses the data and sends the data for some possible causes of failure and recovery methods to Application Server.
Data
Edge/ Fog Network
Edge/Fog
Node A
Edge/Fog
Node B
Data
6a. Edge/Fog Node A stores the data for future trouble shooting of Factory A
2. Edge/Fog Node B detects a system fault of Factory B.
Node B gets video clips of surveillance cameras in the factory for further investigation.
5a. Edge/Fog Node B sends the data to Edge/Fog Node A
Local Network
Data
5. Edge/Fog Node B sends the data to Factory B.
Mobile Base Station
Mobile Base Station
Data
Data
Data
1. All of sensor data are sent to Edge/Fog Node B periodically via Factory GW.
Data
6. Factory B receives the data and executes the recovery method.
Factory B
Factory A

17. Next Steps

18. oneM2M TSs/TRs TSs/TRs related to Edge/Fog computing are as follow.
No explicit use case exists
TR-0001 Use Cases Collection
TR-0013 Home Domain Enablement
TR-0018 Industrial Domain Enablement
TR-0026 Vehicular Domain Enablement
Some requirements exist
TS-0002 Requirements(see Annex)
Message aggregation, Group management, Event categories, Geographical location, Low latency.
Some functions exist
TS-0001 Functional architecture
CMDH(Communication Management and Delivery Handling), GMG(Group management), Cross Resource Subscription.

19. Edge/Fog computing WI Options
Option1 New WI, reuse existing TSs/TRs.
New WI includes CRs to existing TSs/TRs, e.g.:
Architecture -> TS-0001 Functional Architecture
Use cases > TR-0001 Use Cases Collection (with options for vehicular use cases in TR-0026 and industrial use cases in TR-0018, or all in TR-0001)
Option2 New WI, new TR with all work
New WI includes new TR and CRs to existing TSs/TRs.
The scope of new TR is
Use cases and potential requirements.
Gap/ architectural analysis
Key issues and solutions for future TS works.
Option3 New WI, new TR for analysis only.
Gap analysis
Key issues and solutions
Use cases and requirements in existing TRs/TSs.
After choosing an option, embedded draft will be modified accordingly.

20. Annex

21. Existing TS-0002 Requirements possibly related to Edge/Fog computingNo
Requirement
Rel
OSR-019
The oneM2M System shall support the capabilities for data repository (i.e. to collect/store) and for data transfer from one or more M2M Devices or M2M Gateways, for delivery to one or more M2M Gateways, M2M Services Infrastructure, or M2M Application Infrastructure, in ways requested by the M2M Application Infrastructure as listed below: • action initiated either by an M2M Device, M2M Gateway, M2M Services Infrastructure, or M2M Application Infrastructure; • when triggered by schedule or event; • for specified data.
Implemented in Rel-1
CMDH
OSR-021
The oneM2M System shall be able to provide mechanisms to enable sharing of data among multiple M2M Applications.
OSR-029
The oneM2M System shall be able to support sending common command(s) to each actuator or sensor via a group.
GMG
OSR-030
The oneM2M System shall be able to support the management (i.e. addition, removal, retrieval and update) of the membership of a group.
OSR-031
The oneM2M System shall be able to support a group as a member of another group.
OSR-032
The oneM2M System shall be able to support Event Categories (e.g. normal, urgency) associated with data for M2M Applications when collecting, storing and reporting that data (see note 6:Based on the Event Categories and via interworking with Underlying Networks, the oneM2M System can support differentiated services (by providing Quality-of-Service) requested by M2M Applications.).
OSR-033
Based on the Dynamic Device/Gateway Context of the M2M Gateway and/or Device and the defined Event Categories, the oneM2M System shall provide the capability to dynamically adjust the scheduling of reporting and notification of the M2M Device/Gateway (see note 17).
Partially implemented TR
OSR-036
The oneM2M System should provide mechanisms to accept requests from M2M Application Service Providers for compute/analytics services.
Not implemented
DMR
OSR-037
The oneM2M System shall enable an M2M Application to request to send data, in a manner independent of the Underlying Network, to the M2M Applications of a group of M2M Devices and M2M Gateways in geographic areas that are specified by the M2M Application.
OSR-038
The oneM2M System shall support the inclusion of M2M Application's QoS preference in service requests to Underlying Networks.
OSR-039
The oneM2M System shall be able to authorize service requests with QoS preference at service level, but shall pass M2M Application's QoS preference in service requests to Underlying Network for authorization and granting or negotiation of the service QoS requests.
OSR-047
The oneM2M System shall be able to support mechanism for the M2M Devices and/or Gateways to report their geographical location information to M2M Applications (see note 7). TR
OSR-048
The oneM2M System shall provide an M2M Service that allows M2M Devices and/or Gateways to share their own or other M2M Devices' geographical location information (see note 7).
OSR-063
The oneM2M System shall be able to manage the scheduling of M2M Service Layer connectivity and messaging between the Infrastructure Domain and M2M Devices/Gateways.
OSR-064
The oneM2M System shall be able to aggregate messages depending on message delay tolerance and/or category.

22. Existing TS-0002 Requirements possibly related to Edge/Fog Computing(cont.)No
Requirement
Rel
OSR-065
The oneM2M System shall provide mechanisms that enable a M2M Service Provider to distribute processing functions to his M2M Devices/Gateways in the Field Domain
Not implemented
CMDH
OSR-088
The oneM2M System shall be able to support the capabilities for data repository (i.e. to collect/store) and for data transfer from one or more M2M Devices or M2M Gateways, for delivery to one or more M2M Gateways via M2M Area Network without any assistance or instruction of M2M Management Servers and M2M Application Servers(OSR-088).
Implemented in Rel-1 TR
OSR-099
The oneM2M system shall enable continuity of services to M2M devices as they move across various geographic points in the oneM2M System(s).
Implemented in Rel-3 TR
OSR-104
Upon request from M2M Application Server, an M2M Gateway or M2M device shall enable functions that pre-process (e.g. average) M2M data before providing them to the recipient.
OSR-105
Upon request, an M2M Gateway or M2M device shall enable functions that erase M2M data (e.g. that have been sent or could not be sent to the recipient within a certain time) based on criteria from an M2M Application.
OSR-108
The oneM2M System shall enable M2M Gateways to set conditions used for processing jointly group/aggregate data subscriptions to reduce the number of messages to M2M Devices and distribute the resulting notifications according to the set conditions.
OSR-109
The oneM2M System shall enable M2M Gateways to distribute notifications according to how data subscriptions have been grouped/aggregated.
OSR-110
The oneM2M System shall enable subscriptions to changes to multiple data sources (e.g. oneM2M resources) which aim to generate data publication (i.e. automatic notifications) if and only if the expected changes to each of those multiple resources occur concurrently.
OSR-112
The M2M System shall enable the M2M Application to configure the notification interval in the M2M Devices. TR
OSR-115
A M2M system shall be able to support service requests from M2M applications for communication with QoS requirement, such as, higher delivery priority, reliable delivery, etc.
Partly implemented TR
OSR-117
The oneM2M System shall support setting the configuration for Geo-Fence based location services by a M2M Application.
Implemented in Rel-2 TR
OSR-124
OneM2M System shall be able to transfer the information on real-time basis for feeding back current road states to automatic driving control. The feedback time should be less than a few seconds (the distance between vehicles normally corresponds to a few seconds) to avoid unnecessary speed down/stop of following vehicles.
Rel-3/ future releases? TR
OSR-130
The oneM2M System shall enable the M2M Infrastructure to facilitate direct communication between two or more different M2M devices without having registered with one another. TR
OSR-132
The oneM2M System shall be able to verify time synchronization TR
CMR-016
The oneM2M system shall support the data to be transmitted to IoT platform with strict timing and packet loss requirements, determined by the application(s).
Not Implemented TR
CMR-017
The oneM2M system shall support the data to be transmitted from IoT platform to subscribed devices with highest priority, with strict timing and packet loss requirements, determined by the application(s).
MGR-005
The oneM2M System shall provide the capability to manage multiple devices in a grouped manner.
GMG