Onem2m system and a method for provisioning of field gateways

Abstract

In one embodiment, an oneM2M system is disclosed. The oneM2M system comprises an infrastructure domain comprising an infrastructure node, a field domain comprising at least one field gateway in communication with the infrastructure node, one or more field devices in communication with the field gateway. The infrastructure node is configured to store service profile information for a field gateway corresponding to an application, registration and authentication profile information of field devices, issue the announcement of the service profile information, and an announcement of the stored registration and authentication information of the field devices to the at least one field gateway based on the service profile. The at least one field gateway is configured to receive the stored registration, authentication and service profile information of the field devices configured for this field gateway from the infrastructure node through announcement, determine if the received registration, authentication and service profile information of the field devices exists, store the received registration and authentication information of the field devices based on the determination and allow' resource creation at the at least one field gateway as per the service profile configured on at least one field gateway.

Description

oneM2M System and a Method for Provisioning of Field GatewaysFIELD OF INVENTION

[0001] Embodiments of the present application relates to oneM2M standard and more particularly to enabling service profile for field gateway oneM2M nodes and provisioning them with the information of the field nodes (ADN, ASN), allowing it to connect securely to only limited, provisioned field nodes and apply service restrictions.BACKGROUND OF THE INVENTION

[0002] oneM2M standard is a global initiative for IoT / M2M domain standardization. In oneM2M architecture, there are two domains- infrastructure domain and field domain. IN-node sits in infrastructure domain while Application dedicated node (ADN), Middle node (MN) and Application Service Node (ASN) sit in field domain. Devices in the field domain that host oneM2M Application Entities (AE) and Common Service Entity (CSE) require configuration / pre-provisioning with device related information which enables them to perform registration and eventually successfully operate in the M2M Service Layer. The goal of oneM2M is to develop M2M service layer standards which address the need of various industry loT verticals. It not only provides the common sendee functions which are required by various vertical but also provides means to integrate with existing loT technologies and standards. Existing M2M / IoT solutions across verticals are fragmented and not able to interface and exchange data. True loT can be achieved when entities of various verticals can communicate seamlessly. With that goal, various standard bodies across the world collaborated to come up with standards of loT.

[0003] An M2M Application Provider is responsible for developing and operating M2M (Machine-to-Machine) applications. These applications typically interact withdevices, sensors, and systems to provide specific functionalities or services to end users. For every M2M application, a contract is established between M2M application provider and M2M service provider. This contract is stored in the IN-Node in the form of service profile. This Service profile is used to impose service restriction on the resource operations performed by the field devices. Further, IN-CSE has preconfigured information for this field device well as information related to its security credentials. Through the concept of service profile and pre-configured information of the field devices, IN-Node ensures communication with limited, known and identifiable field devices.

[0004] The way IN-CSE has service profile and preconfigured information for its field domain AEs / Nodes, similarly field gateway should also have service profiles which is derived from service profile stored at IN-CSE corresponding to an application provider and should also be allowed to impose service restrictions to field devices based on this service profile if required. This service profile is referred as field gateway service profile. It should also be possible to configure the field gateways with registration and security profile of its field devices based on this field gateway service profile. This information at field gateway will enable them to communicate with only limited, known and identifiable field devices.SUMMARY OF THE INVENTION

[0005] The following presents a simplified summary of the subject matter in order to provide a basic understanding of some of the aspects of subject matter embodiments. This summary is not an extensive overview of the subject matter. It is not intended to identify key / critical elements of the embodiments or to delineate the scope of the subject matter. Its sole purpose is to present some concepts of the subject matter in a simplified form as a prelude to the more detailed description that is presented later.

[0006] In one embodiment, an oneM2M system is disclosed. The oneM2M system comprises an infrastructure domain comprising an infrastructure node, a field domain comprising at least one field gateway in communication with the infrastructure node, one or more field devices in communication with the field gateway. The infrastructure node is configured to store service profile for the application provider, store field gateway service profile, store registration and authentication and profile information of field devices, issue the announcement of the field gateway service profile to field gateway, issue an announcement of the stored registration and authentication information of the field devices to the at least one field gateway based on the field gateway service profile. The at least one field gateway is configured to receive the stored field gateway service profile on the at least one field gateway corresponding to an application, registration and authentication profile information of the field devices configured for the at least one field gateway from the infrastructure node through announcement, determine if the received field gateway service profile information on the field gateway exists, determine if the received registration, authentication profile information of the field devices exists, store the received field gate way service profile information on the field gateway corresponding to an application, store the received registration and authentication information of the field devices based on the determination, allow secure communication with only those field devices whose authentication profile is configured at field gateway, allow registration of only those field devices whose registration profile is configured to field gateway and apply service restrictions on resource creation at the field gateway as per the field gateway service profile configured at field gateway.

[0007] In another embodiment, a method for providing oneM2M system is disclosed. The method comprises storing, by an infrastructure node, field gateway service profile, storing, by the infrastructure node, registration and authentication and profile information of field devices, issuing, by the infrastructure node, the announcement ofthe field gateway service profile to field gateway, issuing, by the infrastructure node, an announcement of the stored registration and authentication information of the field devices to the at least one field gateway based on the field gateway service profile, receiving, by at least one field gateway, the stored field gateway service profile on the at least one field gateway corresponding to an application, registration and authentication profile information of the field devices configured for the at least one field gateway from the infrastructure node through announcement. The method further comprises determining, by the at least one field gateway, if the received field gateway service profile information on the field gateway exists, determining, by the at least one field gateway, if the received registration, authentication profile information of the field devices exists, storing, by the at least one field gateway, the received field gateway service profile information on the field gateway corresponding to an application, storing, by the at least one field gateway, the received registration and authentication information of the field devices based on the determination, allowing, by the at least one field gateway, secure communication with only those field devices whose security profile is configured at field gateway, allowing, by the at least one field gateway, registration of only those field devices whose registration profile is configured to field gateway, applying, by the at least one field gateway, service restrictions on resource creation at the field gateway as per the field gateway service profile configured at field gateway,

[0008] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description, drawings, and claims.BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

[0009] The following drawings are illustrative of particular examples for enabling systems and methods of the present disclosure, are descriptive of some of the methodsand mechanism, and are not intended to limit the scope of the invention. The drawings are not to scale (unless so stated) and are intended for use in conjunction with the explanations in the following detailed description.

[0010] FIG. 1 illustrates a block diagram of oneM2M architecture, in accordance with an example implementation of the present subject matter.

[0011] FIG. 2 shows examples of common service functions (CSF) supported by oneM2M system, in another example implementation of the present subject matter.

[0012] FIG. 3 show's an example of oneM2M architecture illustrating configurations supported by oneM2M architecture an example implementation of the present subject matter.

[0013] FIG, 4 illustrates important components of oneM2M system is shown, in accordance with one embodiment of the present invention

[0014] Figure 5a-5j shows details about each step performed by various entities defined in the oneM2M system, in accordance with an example implementation of the present subject matter.

[0015] Figure 6 shows a method for providing oneM2M system, in accordance with an example implementation of the present subject matter.

[0016] A person skilled in the art will appreciate that elements in the figures are illustrated for simplicity and clarity and may represent both hardware and software components of the system. Further, the dimensions of some of the elements in the figure may be exaggerated relative to other elements to help to improve understanding ofvarious exemplary embodiments of the present disclosure. Throughout the drawings, it should be noted that like reference numbers are used to depict the same or similar elements, features, and structures.DETAILED DESCRIPTION

[0017] Exemplary embodiments now will be described. The disclosure may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey its scope to those skilled in the art. The terminology used in the detailed description of the particular exemplary embodiments illustrated in the accompanying drawings is not intended to be limiting. In the drawings, like numbers refer to like elements.

[0018] OneM2M release 4 specifies 16 common service functions (CSFs) offered in the form of standard APIs to IOT / M2M application providers. FIG. 1 illustrates block diagram of OneM2M architecture 100 according to one example embodiment of the present invention. As shown, the architecture 100 defines a Common Service Entity (CSE) 102 that supports four reference points. The Mca reference point interfaces with the Application Entity (AE) 104. The Mcc reference point interfaces with another CSE 102 within the same sendee provider domain and the Mcc' reference point interfaces with another CSE in a different service provider domain. The Men reference point interfaces with the underlying network service entity (NSE) 106. The NSE 106 provides underlying network services to the CSEs 102. Example network services include, without limitation, device management, location services, and device triggering. A CSE contains multiple logical functions referred to as Common Service Functions (CSFs), which include, by way of example, “Discovery” and “Data Management & Repository”.

[0019] The CSE 102 represents a set of "common service functions" of the M2M environments. Such service functions are exposed to other entities through the reference points. Each Common Service Entity is identified with a unique CSE-ID.

[0020] Further, the AE 104 is an entity in the application layer that implements an M2M application service logic. Each application service logic can be resident in a number of M2M nodes and / or more than once on a single M2M node. Each execution instance of an application service logic is termed an " Application Entity" (AE) and is identified with a unique AE-ID. Examples of the AEs include an instance of a fleet tracking application, a remote blood sugar monitoring application, a power metering application, or a controlling application.

[0021] Field devices are provided which contains devices attached to the oneM2M system for interworking purposes, such as management purposes for example. The field devices utilizes the services offered by M2M service layer. However, for any field device to utilize the services offered by M2M service layer, registration of AE / CSE hosted on field device to the IN-CSE or field gateway is required.

[0022] Referring to FIG. 2 now, examples of common service functions (CSF) supported by oneM2M are illustrated. Various CSFs supported by oneM2M includes, but not limited to, Registration, Data management and Repository, Communication Management, Transaction Management, Discovery, Subscription and notification, Network service Exposure, Semantics, Security, Device management, location, time management, group management, application and service management, service charging and accounting and service management.

[0023] Referring to FIG. 3 now, an example of oneM2M architecture is shown illustrating configurations supported by oneM2M architecture. The oneM2Marchitecture comprises various nodes, such as an application service node (ASN), an application dedicated node (ADN), a middle node (MN), an infrastructure node (IN), and a non-oneM2M node (NoDN). An ASN refers to a node that contains one CSE and contains at least one AE. By way of example, an ASN can reside in an M2M device. An ADN refers to a node that contains at least one AE. ADNs may be present in the field domain of the oneM2M system. An MN refers to a node that contains one CSE. There may be zero or more MNs in the field domain of the oneM2M system. By way of example, an MN can reside in an M2M gateway. An IN refers to a node that contains one CSE. An NoDN refers to a node that does not contain oneM2M entities (neither AEs nor CSEs).

[0024] The M2M Application Provider is responsible for developing and operating M2M (Machine-to-Machine) applications. These applications typically interact with devices, sensors, and systems to provide specific functionalities or services to end users. For e.g. smart homes applications, industrial loT application or Healthcare applications. The M2M Service Provider provides the underlying platform, connectivity, and infrastructure to support these applications. M2M Node is a logical entity that is identifiable in M2M system.

[0025] Whenever an M2M application provider wants to utilize services provided by M2M Service provider, a contract is established between them. This contract is basically a Service subscription profile and used to impose service restrictions on the M2M Nodes acquired by M2M application provider. Once the Sendee subscription profile is created, Admin AE on behalf of M2M application provider initiates the enrollment / Configuration of M2M field nodes in M2M service provider domain. M2M service provider on the basis of the restriction defined in the contract configures the nodes.

[0026] As mentioned before, each field device application instance i.e. AE is required to register with the CSE for availing of the services offered by CSE as per its service subscription profile. Further, it is required that the device is preconfigured with its security profile and registration profile. 0neM2M through its field device configuration mechanism enables configuration of these profiles in field devices.

[0027] To enable configuration of field devices, firstly IN-CSE is configured with the information of all the field devices. If any device is being introduced in the M2M system, the first step is to configure information of the field device at the IN-CSE. Hence, IN-CSE always have prior know ledge of incoming field devices.

[0028] Similarly, devices in the Field Domain that host oneM2M AEs or CSEs are provisioned with the information required by them for security and registration. This enables them to enroll securely and perform registration and eventually successfully operate in the M2M Service Layer. Further, configuration of the field devices at IN- CSE is determined by Service profile at IN-CSE. For e.g., the number of nodes that can be added for an application provider will be determined by its service profile.

[0029] When the Field Device that host oneM2M AE / CSE comes for registration on IN-CSE, the device’s authenticity is validated with the information which is configured at the IN-CSE. This procedure helps the M2M Service Provider to offer its services only to identified and authenticated Devices and to protect its platform from malicious AE.

[0030] As shown in the FIG. 3, a field device which host AE / CSE can also register itself to the field gateway which host CSE(also known as MN-CSE) and utilize the services offered by field gateway. In order for a field gateway to allow field devices to avail the services of the field gateway, the field gateway is required to be configuredwith profiles of the field device coming for registration. However, existing art has issues w.r.t to field gateway provisioning. First issue is field gateways are not provisioned with the security profile and registration profile of the field devices which will come to register on the field gateway. This could lead to communication of field gateways with unknown and unauthenticated devices.

[0031] Other issues that could arise is that there is no criteria as to how and when these profiles will be provisioned on field gateways, no provision to define the service profile on the field gateways corresponding to an application at IN-Node, no provision to share service profile with the field gateways, no local mechanism to apply service restriction on field devices registered on field gateways.

[0032] Thus, the present disclosure proposes a procedure for enabling service profile of field gateway corresponding to its primary service subscription profile at IN-CSE for an application. The service profile for field gateway should be used to restrict aggregate amount of Bytes stored, maxUsers, maxRequestRate, maximum number of aggregated data points etc. Further, enabling field gateways to have prior information of the field devices which will utilize the services offered by field gateway nodes present in a particular M2M service provider domain.

[0033] Referring to FIG. 4 now, some of the important components of oneM2M system 100 is shown in accordance with one embodiment of the present invention. The oneM2M system 100 comprises an infrastructure domain 102 comprising an infrastructure node (IN-node) 104, a field domain 106 comprising at least one field gateway 108 in communication with the infrastructure node. The oneM2M system 100 also comprises one or more field devices 110 in communication with the field gateway9259-P13-PCT

[0034] The infrastructure node 104 stores service profile information of the field gateway and registration and authentication profile of the field device. The registration information of the field device contains the information required by the field devices for registering into the oneM2M system 100. In addition to the registration information, the authentication profile of the field devices are also stored. The authentication profile contains unique identification and other attributes of the field device required for secure communication withoneM2M system 100. The service profile information is a contract established between M2M application provider and M2M service provider. This contact is stored in infrastructure Node in the form of service profile. The service profile is used to impose service restriction on the resource operations performed by the field devices on the Infrastructure Node.

[0035] Once all the information related to registration, authentication and service profile for field gateway are stored (preconfigured) at the IN-Node 104, the IN-Node 104 issues an announcement of the service profile for field gateway information to the at least one field gateway. Further, the IN-Node 104 also issues announcement of the stored registration and authentication information of the field devices to the at least one field gateway based on the.

[0036] The at least one field gateway is configured to receive the field gateway service profile, stored registration, authentication profile information of the field devices configured for this field gateway from the IN-Node 104 through the announcement. Once the information is received, the at least one field gateway determines if the received information already exists in the at least one field gateway. In other words, this determination is to check if the field device information is already present / previously registered in the at least one field gateway. If the information is already present, then it is determined that the field device is not a new field device and already existed in the oneM2M system (and also existed at the field gateway).

[0037] However, if the information is not present in the at least one field gateway, then it is determined that the field device is a new field device for the oneM2M system. The information received is then stored at the at least one field gateway. The secure communication with the field device and the registration of field device on the field gateway is then allowed. The service restrictions is then applied at the field gateway as per the application service profile on the gateway. Further, whenever the service profile for the field gateway, registration, authentication and security profiles are updated at the IN-node, these profiles are also updated at the field gateway.

[0038] Each of the field gateway has an identifier and the IN-node is configured to store the identifier of the at least one field gateway. During announcement, the infrastructure node announces the field gateway service profile, registration and authentication profile information to the stored identifier of the at least one field gateway. More details about this will be explained below with reference to FIG. 5a-5j.

[0039] The present invention will now be explained with respect to FIG. 5a- 5j illustrating details about each step performed by various entities defined in oneM2M system 100. Whenever any M2M application provider want to utilize the services offered by M2M service provider, they can subscribe to a contract with an M2M Service provider (M2M Service Subscription) under which they enroll their M2M Nodes. M2M service provider Admin User will configure service profile for the application provider as shown in FIG. 5a.

[0040] The Admin AE creates and sends a <m2mServiceSubscriptionProfile> for an M2M Application- Appl to IN-CSE. The <m2mServiceSubscriptionProfile> resource represents an M2M Service Subscription. It is used to represent all data pertaining to the M2M Service Subscription, i.e. the technical part of the contract between an M2M Application Service Provider and an M2M Service Provider and is only stored on IN- CSE.(TS-0001, section 9.6.19).

[0041] FIG.5b shows 2 middle nodes (MN) which are registered at IN-CSE. Although only 2 MNs are shown, there could be multiple MNs which will be registered in the form of <remoteCSE>. A <remoteCSE> resource shall represent a Registree CSE that is registered to the Registrar CSE. <remoteCSE> resources shall be located directly under the < CSEBase> resource of Registrar CSE. Similarly, <remoteCSE> resource shall also represent a Registrar CSE. <remoteCSE> resource shall be located directly under the < CSEBase> resource of Registree CSE. For example, when CSE I (Registree CSE) registers with CSE2 (Registrar CSE), there will be two <remoteCSE> resources created: one in CSE1: < CSEBasel> / <remoteCSE2> and one in CSE2: < CSEBase2> / <remoteCSEl>. FIG.4b shows one such topology deployed with 2 MNs.

[0042] Once the Application deployment topology is available, a new resource <m2mServiceSubscriptionGatewayProfile> will be created for the gateways at IN¬ CSE. This resource will be used to impose service subscription restrictions on field gateways. This is shown in FIG. 5c where the Admin AE will create and send <m2mServiceSubscriptionGatewayProfile> for an M2M Application- Appl (SSGP) to IN-CSE. <m2mserviceSubscriptionGatewayProfile> resource(SSGP) for any field gateway will be derived from <m2mServiceSubscriptionProfile> of any application present at IN-Node. The original resource of SSGP will be present at IN-Node only but this resource’s copy will be made available at field gateway node as well. By utilizing the parameters present in this resource, field gateways will be able to impose service restriction on the resource operation being performed by its registree field device. For e.g., there will be a limit on the aggregated data (bytes) stored on this field gateways, maxUsers allowed, max data points that can be created etc. These resources will be used for provisioning of service restriction on field gateway. Some of the proposed attributes for SSGP resources are shown below:

[0043] When the SSGP resource gets created at IN-Node, the IN-Node will issue an announcement(s) request for SSGP resource to the field gateway represented by the CSE-ID attribute of SSGP resource. This is shown in FIG. 5d, where the announcement request (SSP2-MN1_Annc and SSP3_MN2_Annc) is issued from IN- Node.

[0044] Whenever a new field device is introduced in the M2M service provider domain, Configuration AE sends CREATE request for <serviceSubscribedNode> corresponding to the newly introduced field device. The <serviceSubscribedNode> resource represents M2M Node information that is needed as part of the M2M Service Subscription resource and is only stored on IN-CSE. It contains M2M-Node-ID and optionally CSE-ID running on that Node.(TS-0001, section 9.6.20).

[0045] The introduction of new device is shown in FIG. 5e, where when a new device is introduced for onboarding, <serviceSubscribedNode> resource is created for the new device. The <serviceSubscribedNode> resource may be created by an Admin user at Configurator AE and sent to IN-Node.

[0046] After the successful creation of the <serviceSubscribedNode> resource, the Originator i.e. the configuration AE shall use a CREATE request to create a <node> resource. The <node> resource represents specific information that provides properties of an M2M Node that can be utilized by other oneM2M operations. The <node>resource has specialization of the <mgmtObj> as its child resources. (TS-0001, section 9.6.18). The CREATE request shall address a < CSEBase> of a Hosting CSE. The Originator shall set nodelD attribute of this <node> resource to a value equal to nodelD attribute of the <serviceSubscribedNode> resource. < Node> resource will be created after checking maxNumNodes attribute of <m2mServiceSubscriptionProfile> resource. After checking the SSP, if the maxNumNodes limit is not reached, <node> resource is created. This is illustrated in FIG. 5f.

[0047] The Originator shall use a CREATE request to create a [registration] resource. The request shall address the above-mentioned <node> resource. The Originator shall set M2M-Sub-ID attribute of [registration] resource to a value equal to M2M-Sub-ID attribute of the <m2mServiceSubscriptionProfile> resource which is the parent of this <serviceSubscribedNode> resource. Hosting CSE can use PoA present in <registration> resource to fetch <m2mServiceSubscriptionGateProfile> and check if maxNumAes limit is reached.

[0048] If the node which is represented by this <node> resource intends to use Security’ Association, then the Originator shall use a CREATE request to create an [authenticationprofile] resource. The request shall address the above-mentioned <node> resource. The Originator shall set M2M-Sub-ID attribute of the [authenticationProfile] resource to a value equal to the M2M-Sub-ID attribute of the <m2mServiceSubscriptionProfile> resource which is the parent of this <serviceSubscribedNode> resource.

[0049] This is shown in FIG. 5g, where after checking the SSGP, if maxNumAEs limit is not reached, [registration] and [authenticationProfile] resources are created.

[0050] Referring to FIG. 5h, registration profile and authentication profile is shown. All the information related to field nodes are first configured at IN node. If any of thefield gateways is selected as registrar of these field nodes by an admin AE then information of such field nodes are passed to field gateways using following steps:• IN-Node should issue an announcement request for these 2 resources to the middle node(MN) / field gateway.« To issue the announcement request to MN node, IN-CSE needs to send Create request for [nodeAnnc],[registrationAnnc] and [authenticationProfileAnnc] to the registrar of the field device node.* After receiving this announcement request, MN-CSE shall check if < CSEBaseAnnc> exists. If it does not exist, the Receiver shall create a < CSEBaseAnnc> resource as a child of the < CSEBase> resource of the announcement target CSE.• The Receiver i.e. the field gateway shall then create the [nodeAnnc], [registrationAnnc] and [authenticationProfileAnnc resource as a child of the < CSEBaseAnnc> resource.

[0051] Referring to FIG. Si, AE registration at field gateway is shown. Whenever field device want to utilize the services offered by field gateway, first it has to register in the form of < AE> resources. Field gateway will check if <registrationAnnc> resource is present. If yes, then < AE> resource will be created.

[0052] When AE sends request to create < Container> resource, field gateway checks the <m2mSSGPAnnc> resource whether maxNumContainer limit is reached. If it is not reached then only <container> resource gets created under < AE>. After the <container> resource curNumContainer attribute of <m2mSSGP> get updated and as it is announced resource, it’s corresponding original resource which is present at IN- CSE also gets updated for the same. Resource registration is shown in FIG. 5j. Fieldgateway will check if MaxNumContainer Limit is reached from the M2mSSGPAnnc> resource present. If not, then <container> gets created.

[0053] Referring to FIG. 6 now, a flowchart of a method provided in oneM2M system is illustrated, in accordance with one embodiment of the present disclosure. At step 602, the method comprises storing field gateway service profile corresponding to an application and registration and authentication profile information of field device at the Infrastructure Node. The infrastructure node is present inside an infrastructure domain of the oneM2M system and is in communication with at least one field gateway present in the field domain.

[0054] At step 604, the method comprises issuing announcement of the service profile for field gateway by the infrastructure node to the at least one field gateway and issuing announcement of the stored registration and authentication information of the field devices to the at least one field gateway. At step 606, the method comprises receiving, by the at least one field gateway, the stored field gateway service profile, registration and authentication profile information of the field devices from the infrastructure node through announcement. At step 608, the method comprises determining if the received service profile information on the field gateway corresponding to an application already exists. This involves matching the service profile for field gateway and registration authentication profile information of the field device stored in the at least one field gateway with that of the new field device coming for registration at the field gateway. The new field device is the one which is not previously registered at the at least one field gateway.

[0055] At step 610, the method comprises storing the received registration and authentication information of the field devices based on the determination. This involves storing the profiles information if the profiles information of the new field device is not already stored in the at least one gateway. At step 611, the methodcomprises allowing secure communication with only those field device whose security profile is configured at field gateway. At step 612, the method comprises allowing registration of only those field devices whose registration profile is configures at field gateway. At step 613, the method comprises applying service restrictions at the field gateway as per the field gateway service profile configured on the gateway for this application.

[0056] Referring to FIG.7 now, one practical implementation of the present invention utilizing oneM2M system 100 can be shown in M2M street light application. In the OneM2M street light application, there are ‘n’ number of street lights. These street lights are divided into various zone such that zone 1 street light need to be registered with field gateway 1, zone 2 street light need to be registered with field gateway2 and so on. These field gateways are further registered with IN-CSE to avail service layer operation offered by IN-CSE. When M2M application provider for Street light wants to utilize services offered by M2M service provider, service subscription profile is created for the application. When the topology' is available to the Infrastructure node, Configurator AE creates service profile for the field gateway(SSGP) corresponding to the application. IN-Node then issues announcement of SSGP to field gateway. Whenever new Street light sensor of zonel is introduced. Service provider domain IN- CSE is configured with information of this sensor in the form of mgmt resources i,e, [registration] and [authenticatedProfile] by Configuration AE. IN-CSE then check if the registrar Poa belongs to MN-CSE1, an announcement request is issued to field gateway! for [node], [registration] and [authencationProfile] resources. In this way field gateway 1 have [nodeAnnc],[registrationAnnc] and [authenticationProfileAnnc] resources.

[0057] In one example embodiment, the present disclosure provides for enabling configuration of service profiles at Infrastructure node for each of its field gateway for the applications registering to it.

[0058] In one example embodiment, the present disclosure provides for storing of service profiles at Infrastructure node for each of its field gateway for the applications registering to it.

[0059] In one example embodiment, the present disclosure provides for enabling the configuration of field gateways with the service profile of each application on the field device, performed from the infrastructure node during the field device's configuration process at the infrastructure node.

[0060] In one example embodiment, the present disclosure provides for enabling the configuration of field gateways with the authentication profile of each device from the infrastructure node during the device's configuration process, based on its service profile.

[0061] In one example embodiment, the present disclosure provides for enabling the configuration of field gateways with the registration profile of each device from the infrastructure node during the device's configuration process, based on its service profile.

[0062] In one example embodiment, the present disclosure provides for announcing the field gateway service profiles to the field gateways, stored at the infrastructure node, for applications registering with them in relation to the corresponding field devices.

[0063] In one example embodiment, the present disclosure provides for storing the announced field gateway service profile at the field gateways for the applications registering to it.

[0064] In one example embodiment, the present disclosure provides for storing the authentication profile of each field device coming for security interface at the field gateway.

[0065] In one example embodiment, the present disclosure provides for storing the registration profile of each field device coming for registration at the field gateway.

[0066] In one example embodiment, the present disclosure provides for updating the field gateway service profile, authentication profile and registration profile of each field devices at the field gateway when these profiles are updated at infrastructure node.

[0067] In one example embodiment, the present disclosure provides for matching these profiles against each application / node coming for registration.

[0068] In one example embodiment, the present disclosure provides for allowing only those devices to register whose profile matches at field gateway.

[0069] In one example embodiment, the present disclosure provides for allowing resource creation at the field gateway as per the application service profile configured on the gateway for this application.

[0070] In the specification, there has been disclosed exemplary embodiments of the invention. Although specific terms are employed, they are used in a generic and descriptive sense only and not for purposes of limitation of the scope of the invention.

Claims

WE CLAIM:

1. A oneM2M system comprising:an infrastructure domain comprising an infrastructure node, a field domain comprising at least one field gateway in communication with the infrastructure node,one or more field devices in communication with the field gateway, wherein the infrastructure node is configured to:store service profile for the field gateway (field gateway service profile) corresponding to an application, store registration and authentication profile information of field devices,issue the announcement of the field gateway service profile to the field gateway;issue an announcement of the stored registration and authentication information of the field devices to the at least one field gateway based on the field gateway service profile,wherein the at least one field gateway is configured to:receive the stored field gateway service profile on the at least one field gateway corresponding to an application, registration and authentication profile information of the field devices configured for the at least one field gateway from the infrastructure node through announcement,determine if the received field gateway service profile information exists.determine if the received registration, authentication profile information of the field devices exists,store the received field gateway service profile information based on the determination,store the received registration and authentication information of the field devices based on the determination, andallow secure communication with only those field devices whose authentication profile is configured at field gateway.allow registration of only those field devices whose registration profile is configured to field gateway.apply service restrictions on resource creation at the field gateway as per the configured field gateway service profile.

2. The system as claimed in claim 1, at least one field gateway is further configured to:receive registration and authentication information of new field device, match the received registration and authentication information of the new field device with the stored registration and authentication information of the new field device at the at least one field gateway,register the new field device at the least one field gateway if there is a match, andapply the service restriction on new field device application as per the field gateway service profde stored at the field gateway.

3. The system as claimed in claim 2, wherein the new field device is not previously registered with any of the at least one infrastructure node and / or the at least one field gateway.

4. The system as claimed in claim 1, wherein each of the at least one field gateway has an identifier, and the infrastructure node is configured to store the identifier of the at least one field gateway.

5. The system as claimed in claim 4, wherein during announcement, the infrastructure node announces field gateway service profile, the registration and authentication profile information to the stored identifier of the at least one field gateway.

6. A method for providing a oneM2M system, the method comprising:storing, by an infrastructure node, field gateway service profile corresponding to an application,storing, by the infrastructure node, registration and authentication profile information of field devices,issuing, by the infrastructure node, the announcement of the field gateway service profile to the at least one field gateway;issuing, by the infrastructure node, an announcement of the stored registration and authentication profile information of the field devices to the at least one field gateway based on the field gateway service profile, receiving, by at least one field gateway, the stored field gateway service profile on the at least one field gateway corresponding to an application, registration and authentication profile information of the field devicesconfigured for the at least one field gateway from the infrastructure node through announcement,determining, by the at least one field gateway, if the received field gateway service profile information on the field gateway corresponding to an application already exists,determining, by the at least one field gateway, if the received registration, authentication profile information of the field devices exists, storing, by the at least one field gateway, the received field gateway service profile information on the field gateway corresponding to an application storing, by the at least one field gateway, the received registration and authentication profile information of the field devices based on the determination, andallowing, by the at least one field gateway, secure communication with only those field devices whose authentication profile is configured on at least one field gateway.allowing, by the at least one field gateway, registration of only those field devices whose registration profile is configured on at least one field gateway.applying, by the at least one field gateway, service restrictions on resource creation as per the field gateway service profile configured on at least one field gateway.

7. The method as claimed in claim 6, further comprising by the at least one field gateway:receiving registration and authentication information of new field device,matching the received registration and authentication information of the new field device with the stored registration and authentication information of the new field device at the at least one field gateway,registering the new field device at the least one field gateway if there is a match, andapplying the service restriction on field device application as per the field gateway service profile stored at the field gateway.

8. The method as claimed in claim 7, wherein the new field device is not previously registered with any of the at least one infrastructure node and / or the at least one field gateway.

9. The method as claimed in claim 6, wherein each of the at least one field gateway has an identifier, and the infrastructure node is configured to store the identifier of the at least one field gateway.

10. The method as claimed in claim 9, wherein during announcement, the infrastructure node announces the field gateway service profile, the registration and authentication profile information to the stored identifier of the at least one field gateway.

Images