[go: up one dir, main page]

WO2012150778A2 - Procédé et un appareil de gestion d'une connexion entre des objets de communication basée sur un événement de confirmation d'état de connexion - Google Patents

Procédé et un appareil de gestion d'une connexion entre des objets de communication basée sur un événement de confirmation d'état de connexion Download PDF

Info

Publication number
WO2012150778A2
WO2012150778A2 PCT/KR2012/003284 KR2012003284W WO2012150778A2 WO 2012150778 A2 WO2012150778 A2 WO 2012150778A2 KR 2012003284 W KR2012003284 W KR 2012003284W WO 2012150778 A2 WO2012150778 A2 WO 2012150778A2
Authority
WO
WIPO (PCT)
Prior art keywords
event
information
gateway
platform
application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/KR2012/003284
Other languages
English (en)
Korean (ko)
Other versions
WO2012150778A3 (fr
Inventor
윤성숙
김유선
김의직
배정일
장덕문
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
KT Corp
Original Assignee
KT Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020110055982A external-priority patent/KR20120124345A/ko
Application filed by KT Corp filed Critical KT Corp
Publication of WO2012150778A2 publication Critical patent/WO2012150778A2/fr
Publication of WO2012150778A3 publication Critical patent/WO2012150778A3/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications

Definitions

  • Thing communication or communication between things means communication made between devices.
  • the communication between the objects is implemented differently from the communication of the conventional mobile phone in that it has a feature of transmitting and receiving various information in accordance with a specific pattern.
  • the present specification provides a method and apparatus for managing a connection between M2M communication entities by providing a connection state checking event method in implementing such a thing communication.
  • the thing communication is variously called as machine to machine communication (M2M), machine type communication (MTC), Internet of Thing (IoT), smart device communication, or machine oriented communication.
  • Things communication refers to all communication methods in which a communication is made without a person intervening in the communication process.
  • the thing communication has a variety of communication patterns depending on the market (application), application (application), or service (service) to be applied.
  • the information to be transmitted and received may also be transmitted and received with a predetermined pattern, or may transmit and receive data without the pattern.
  • the present invention can monitor the period and allowable delay information according to the related application in the M2M gateway and M2M device to notify the platform to manage the effective and reliable M2M gateway and device to solve the problems of the prior art. Make sure In addition, the platform monitors each M2M gateway and device to provide information related to connection confirmation required by the corresponding application.
  • the event management information indicates setting, changing, or deleting an event, setting an event in the M2M gateway or the M2M device; Transmitting event information indicating change or deletion to the M2M gateway or the M2M device, and receiving a processing result from the M2M gateway or the M2M device and transmitting the result to the M2M application, wherein the event management
  • the processing result includes event notification of the M2M gateway or the M2M device
  • the event management information is a service capability provided by the M2M platform.
  • Management Service Capability Control and the event information is characterized in that the control in the connection management service functions provided by the M2M gateway or the M2M device.
  • a method of managing a connection in a device connected to an M2M platform includes: receiving, by the device connected to the M2M platform, event information indicating the setting, change, or deletion of an event from the M2M platform; And transmitting, to the M2M platform, a processing result of processing the instruction work, and when the event information indicates setting or changing of an event, the transmitting step includes notifying the set or changed event.
  • the event information is controlled by a connection management service function, and includes information on a notification period of the event.
  • the M2M platform is an application interworking module for receiving event management information from the M2M application indicating event setting, change, inquiry, or deletion for connection management of an M2M gateway or M2M device, the event A connection management module for recording, changing, or deleting management information in a database according to the instruction, a monitoring module for monitoring an event transmitted by the M2M gateway or an M2M device, and the event management information setting, changing, or deleting an event.
  • the event information instructing the M2M gateway or the M2M device to set, change or delete an event is transmitted to the M2M gateway or the M2M device, and the processing result is received from the M2M gateway or the M2M device.
  • the monitor A module and a gateway / device interworking module for providing information to the application interworking module, wherein the event management information is controlled by a connection management service capability, which is a service capability provided by the M2M platform, and the event.
  • the information is controlled by a connection management service function provided by the M2M gateway or the M2M device.
  • An apparatus is a platform interworking module for receiving event information indicating the setting, change, or deletion of an event from the M2M platform and transmits the processing result of processing the instruction task to the M2M platform, and And a management / monitoring module for managing and monitoring an event to notify the M2M platform of an event according to the setting and change when the event information indicates setting or change of an event, wherein the event information includes a connection management service function.
  • Control in the, characterized in that it comprises information on the notification period of the event.
  • the M2M gateway and the device to periodically transmit a connection status check event to the platform to reliably manage other events delivered from the gateway and the device. .
  • FIG. 1 is a view showing the structure of an M2M system according to an embodiment of the present specification.
  • FIG. 2 is a diagram illustrating a configuration of connection management between an M2M platform and an M2M gateway / device according to an embodiment of the present specification.
  • FIG 3 is a diagram illustrating a configuration of an M2M platform, an M2M device, and an M2M gateway according to an embodiment of the present specification.
  • FIG. 4 is a diagram illustrating a process of setting or changing an event for checking a connection state according to an embodiment of the present specification.
  • FIG. 5 is a diagram illustrating a process of notifying of an event for connection management according to an embodiment of the present specification.
  • FIG. 6 illustrates a process in which a gateway or a device performs event notification for two or more applications according to an embodiment of the present specification.
  • FIG. 7 is a diagram illustrating an example in which the platform performs event notification to an application according to an application notification policy according to an embodiment of the present specification.
  • FIG. 8 is a diagram illustrating an example in which the platform performs event notification to an application according to an application notification policy according to another embodiment of the present specification.
  • FIG. 9 is a diagram illustrating an example in which the platform performs an event notification to an application according to an application notification policy according to another embodiment of the present specification.
  • FIG. 10 illustrates a case in which an application requests an inquiry of a connection status confirmation event from a platform according to an embodiment of the present specification.
  • FIG. 11 is a diagram illustrating a case in which an application requests deletion of a connection status confirmation event from a platform according to an embodiment of the present specification.
  • FIG. 12 is a diagram illustrating a process of managing connection between entities according to one embodiment of the present specification.
  • FIG. 13 is a diagram illustrating a process of managing connection of another device in an M2M application according to one embodiment of the present specification.
  • FIG. 14 is a diagram illustrating a process of managing connection of another device according to an instruction or request of an M2M application in an M2M platform according to one embodiment of the present specification.
  • 15 is a diagram illustrating a process of managing a connection in a device connected to an M2M platform according to one embodiment of the present specification.
  • M2M is divided into various fields, such as M2M, MTC, IOT, smart device communication, and object-oriented communication, and will be described with reference to M2M.
  • this description is not limited to the M2M, and is applicable to all systems and structures for providing device-to-device communication, that is, thing communication, and communication occurring in these systems.
  • FIG. 1 is a view showing the structure of an M2M system according to an embodiment of the present specification.
  • the overall configuration is composed of a network and application domain (110) and M2M device domain (120), the network / application domain (110) is M2M Service Capabilities M2M SC (M2M Service Capabilities) Communication with the M2M application 111 that accesses or provides service logic, the M2M Core 114 composed of the Core Network and the SC, and the M2M device domain 120. Access Network 115, and M2M Management Functions 118 and Network Management Functions 119.
  • M2M SC M2M Service Capabilities
  • the M2M device domain 120 includes an M2M gateway 121, an M2M device 122 and 125, and an M2M area network 123.
  • the M2M devices 122 and 125 are devices in which M2M applications using the functions of the M2M SC and the network domain are driven.
  • the M2M device may be divided into an M2M application and an M2M SC (122) and an otherwise (125).
  • the M2M gateway 121 includes an M2M SC and enables M2M devices to interwork and interconnect in the network / application domain 110.
  • the operation includes not only interworking / interconnection between M2M gateway 212 and M2M devices, but also interworking / interconnection between M2M devices.
  • Service Capabilities or Service Capabilities are meant to provide functionality shared by different applications and the M2M Core 114, M2M Gateway 121, and M2M Devices 122, 125 are required or specific to operate. It may include.
  • the M2M gateway 121 and the M2M devices 122 and 125 communicate with an M2M platform that combines SCs of an M2M core or an M2M core, and manages gateways and devices in lower layers in the M2M platform.
  • the functions for managing gateways and devices in the M2M platform are divided into Network Remote Entity Management (NREM) SC, and the NREM SC is divided into configuration management, fault management, and performance management. Lose.
  • NREM Network Remote Entity Management
  • M2M gateways and M2M devices need to send fault information and status information change events such as battery level and CPU usage to the platform, and the platform must also be able to receive these events.
  • the connection between the M2M gateway and the M2M device and the platform should always be in a normal state. If the connection between the M2M gateway and the M2M device and the M2M platform is not properly performed, events sent from the M2M gateway and the M2M device may not be delivered to the M2M platform. In this case, even if a problem occurs in the M2M gateway and the M2M device, higher-level platforms or applications do not manage this properly, and therefore, problem management may not be performed properly.
  • FIG. 2 is a diagram illustrating a configuration of connection management between an M2M platform and an M2M gateway / device according to an embodiment of the present specification.
  • FIG. 2 illustrates a configuration for implementing connection management, and illustrates a configuration between an application and a connection management service capabilities (SC) between respective M2M platforms and M2M gateways / devices.
  • the M2M platform 240 is composed of a plurality of SCs 245, 248, and 249.
  • SC connection management service capabilities
  • the network connection management SC 245 receives a request for setting / changing / deleting a periodic connection state check event for a gateway and a device from the application 250, and transmits information according to the event monitoring status to the application.
  • it checks the status of event reception to monitor whether there is a situation corresponding to the application notification policy, and sends a connection status check event setting / change / delete request to the gateway and the device, and receives the connection status check event from the gateway and the device. do.
  • the M2M device 210 is composed of an M2M application 212 and a Device Connection Management Service Capabilities (SC) 215.
  • the device connection management SC 215 receives a connection status check event setting / change / delete request from the M2M platform 240, transmits a connection status check event, and manages and monitors the content of the connection status check event.
  • the M2M gateway 220 includes an M2M application 222 and a gateway connection management service capabilities (SC) 225.
  • the gateway connection management SC 225 receives a connection status check event setting / change / delete request from the M2M platform 240, transmits a connection status check event, and manages and monitors the content of the connection status check event.
  • the M2M device 210 and the M2M gateway 220 may exchange information with the M2M platform 240 using the mId interface.
  • Applications 212 and 222 in M2M device 210 and M2M gateway 220 may exchange information with SCs 215 and 225 using dIa interfaces.
  • the M2M application 250 and the M2M platform 240 may exchange information using the mIa interface.
  • the M2M device 210 and the M2M gateway 220 may include a plurality of SCs, and may exchange data with the connection management SC and operate together.
  • SC is not shown in Figure 2 because it is not the main element of the present specification.
  • the connection management service capability of FIG. 2 may be configured as a sub SC of REM (Remote Entity Management), which is one of the SCs of the existing M2M, or may be a sub component. Of course, it can be configured as a separate SC to provide functionality in the M2M platform and services.
  • SC of the M2M is a sub-SC of REM
  • the device connection management SC (DCMSC) 215 becomes a sub-SC of the Device Remote Entity Management (DREM)
  • the gateway connection management SC (GCMSC) 225 is a GREM ( It is a sub-SC of Gateway Remote Entity Management
  • the connection management SC (NCMSC) 245 of the platform is a sub-SC of Network Remote Entity Management (NREM).
  • NREM Network Remote Entity Management
  • the M2M applications 111 and 250 included in the network / application domain are located outside the M2M service and exchange information with the M2M platform.
  • the M2M applications 212 and 222 present in the M2M device domain are M2M applications installed in the M2M device or the M2M gateway and transmit or receive data or transmit information with the M2M applications 111 and 250 included in the network / application domain described above. Interaction, such as exchange.
  • 3 is a diagram illustrating a configuration of an M2M platform, an M2M device, and an M2M gateway according to an embodiment of the present specification. 3 illustrates a case where an event is transmitted to provide a connection management SC.
  • An event collectively refers to information transmitted and received between an M2M platform and an M2M device or an M2M platform and an M2M gateway to provide a connection management SC. Contains information in all manner of verifying the connection, such as heartbeat in common communications. The following event may be an embodiment of all information transmitted and received between entities for the connection management SC.
  • the application interworking module 342 receives a request for setting / changing / deleting periodic connection status check events for the gateway and the device, and sends information according to the event monitoring status to the M2M application 350. Send.
  • the connection management module 344 manages information for checking connection status, for example, setting / changing / deleting an event and updating the corresponding content according to the received event.
  • the connection management module 344 may be a module for managing an event.
  • the monitoring module 346 monitors whether the event corresponding to the application notification policy exists by checking the reception status of the event, which is information for checking the connection status.
  • the gateway / device interworking module 346 transmits a request for setting / changing / deleting an event, which is information for confirming a connection state, to the gateway and the device, and receives a connection state confirmation event from the gateway and the device.
  • the platform interworking module 312 and the management / monitoring module 314 are sub-modules configuring the M2M device 310 or the M2M device 310.
  • the platform interworking module 312 receives a connection state confirmation event setting / change / delete request from the platform 340, and transmits a connection state confirmation event to the platform 340.
  • the management / monitoring module 314 manages and monitors connection status confirmation event contents.
  • connection management SC there are also a platform interworking module 322 and a management / monitoring module 324 as the sub-module constituting the M2M gateway 320 or the M2M gateway 320.
  • the platform interworking module 322 receives a connection status confirmation event setting / change / delete request from the platform 340, and transmits a connection status confirmation event to the platform 340.
  • the management / monitoring module 324 manages and monitors connection status check event contents.
  • Each of the modules in FIG. 3 represent logical functions that must be implemented within the M2M platform 340, the M2M device 310, and the M2M gateway 320 to provide a connection management SC, while at the same time the physical components that implement these functions. Indicates. Thus, these modules may be associated modules may be implemented in one physical component, or one module may be implemented as a collection of a plurality of physical components.
  • M2M gateway / device since the M2M device 310 and the M2M gateway 320 have the same function or module configured in connection with connection management, some descriptions may be collectively referred to as an M2M gateway / device.
  • an embodiment of information for connection management will be described based on an event, and the connection management module of the platform will be described based on an event management module.
  • M2M gateways and M2M devices ensure that they send a connection status check event to the M2M platform before an acceptable delay, and then The event is sent to the M2M platform, and the M2M platform monitors the content of the received connection status check event. Also, by notifying the M2M application and the status of the connection status check event reception status to the corresponding M2M application according to the predefined M2M application, the M2M platform or the M2M application to check whether the connection status with the M2M gateway and the M2M device is normal, Allows for normal coping with fault events.
  • FIG. 4 is a diagram illustrating a process of setting or changing an event for checking a connection state according to an embodiment of the present specification.
  • the M2M application 401 transmits a connection state confirmation event setting / change request message for a specific gateway / device to an application interworking module of the M2M platform 402 (S410).
  • the request message transmitted that is, the connection status check event setting / change request message for a specific gateway or device received by the application interworking module of the M2M platform 402 from a plurality of applications includes an eventSetModObjAPP for event setting / change information.
  • the request message transmitted that is, the connection status check event setting / change request message for a specific gateway or device received by the application interworking module of the M2M platform 402 from a plurality of applications includes an eventSetModObjAPP for event setting / change information.
  • the configuration of Table 1 is an embodiment, and may exclude some, add additional information, or combine some of the information for implementation of the configuration of Table 1. Embodiments of excluding, adding to, and combining some of the information also apply to Tables 2 to 7, which will be described later.
  • Table 1 shows the attributes of the
  • Table 1 Configure event set / change information_APP (eventSetModObjAPP) Attribute Explanation application ID
  • Application ID requesting a connection health check event application_address Address of application requesting connection health check event
  • EventID Identification Information for Connection Status Check Events Gateway_or_device Whether the destination for the connection status check event is a gateway or a device Gateway / device_ID Destination ID (SCL ID) to which to send the connection status check event.
  • Gateway / device_address Destination address to send link health check event to Cycle How often to send link health check events Allowable delay time Delayed Transmission Time of Connection Status Check Events policyType Application notification policy upon receiving connection status check event waitingCount Wait time when no application is received
  • 'application_ID' is identification information of an application requesting a connection status confirmation event
  • 'application_address' is information indicating an address of an application requesting a connection status confirmation event or information related to the address.
  • 'application_address' can be used when not receiving a connection status confirmation event according to the connection status confirmation event notification policy.
  • 'Gateway_or_device' is information for configuring whether a destination for sending a connection status check event is a gateway or a device.
  • 'EventID' means identification information of a connection status check event. This makes it possible to distinguish the event that checks the connection status from other events when various events exist.
  • an event notification function that checks a connection state such as heartbeat uses the same operation as another event notification function, this event may be used as an event identifier to distinguish the event from other events.
  • 'Gateway / device_ID' presents identification information of a target to which a connection status confirmation event is to be sent, and may use a Service Capability Layer ID (SCLID).
  • SCLID may have a tree structure as follows.
  • 'Gateway / device_address' is information of destination address to send connection status check event. Used when sending connection status check event setting / change request It can have the following URI format.
  • 'Period' is information for setting the interval for the gateway / device to send a connection status check event
  • 'Allowable delay time' is information on the delayable transmission time of the connection status check event. Putting an acceptable delay can be caused by problems such as network, gateway / device, or platform overload. Can be used to register multiple applications.
  • 'policyType' may set an application notification policy according to a connection status check event.
  • Notification means providing specific information or informing of occurrence of a specific fact, and means transmitting certain information in a communication system.
  • the following notifications, notifications, and transmissions are used interchangeably.
  • notification policies There are two types of notification policies: i) when a connection status check event is not received, waiting for a certain period (waiting count * cycles), and ii) notifying the application whenever an event comes from the gateway / device.
  • a method of periodically notifying at regular intervals and a method of notifying when an application makes a request may be implemented.
  • 'waitingCount' sets information on waiting time when the application notification policy (policyType) is waited for a predetermined time when an event is not received, as in i). For example, when an event is not received at a designated time, the length of time for waiting for non-receipt can be set. If a specific time unit or period is set, the platform may wait until waitingCount or (waitingCount * cycles) and notify the application.
  • policyType application notification policy
  • the application interworking module transmits the information of the eventSetModObjAPP received in S410 to the event management module (S420).
  • the event management module generates / changes the contents of the event information to be managed in the DB based on the received information (S430).
  • the DB information to be created / modified by the event management module includes event management information, eventMgmtObjPLAT.
  • event management information_PLAT is shown in Table 2.
  • Table 1 will additionally include information related to event reception.
  • event management information_PLAT EventMgmtObjPLAT
  • Application ID requesting a connection health check event application_address Address of application requesting connection health check event
  • EventID Identification Information for Connection Status Check Events Gateway_or_device Whether the destination for the connection status check event is a gateway or a device Gateway / device_ID Destination ID (SCL ID) to which to send the connection status check event.
  • Gateway / device_address Destination address to send link health check event to Cycle How often to send link health check events Allowable delay time Delayed Transmission Time of Connection Status Check Events policyType Application notification policy upon receiving connection status check event waitingCount Wait time when no application is received Event notification time The time when the connection status check event was recently received from the gateway / device. Latest unreceived event notification time The time of the last notification to the application.
  • 'Recent Event Notification Time' and 'Recent Event Notification Time' are added.
  • 'Recent Event Notification Time' stores the time when the connection status check event was recently received from the gateway / device. There is no value at the time of initial DB creation, and it can be updated whenever a connection status check event is notified.
  • the 'not recently received event notification time' is a part of recording when the time of recently notified to the application when the application notification policy is to notify after waiting for a certain period of time when the event is not received.
  • the event management module generates eventSetModObjPLAT, which is event setting / change information to be sent to the gateway / device so that the gateway / device can generate and notify the event according to the set information when the DB setting is completed.
  • This is information to be delivered to the corresponding gateway or device, and is composed of information required to notify an event, and can be implemented as shown in Table 3.
  • the information in Table 3 may be a subset of the information in Table 2.
  • EventSet / Change Information_PLAT (eventSetModObjPLAT) Attribute Explanation application ID
  • Application ID requesting a connection health check event
  • Gateway / device_ID Destination ID (SCL ID) to which to send the connection status check event.
  • Gateway / device_address Destination address to send link health check event to Cycle How often to send link health check events Allowable delay time Delayed Transmission Time of Connection Status Check Events
  • the event management module provides the information on the eventSetModObjPLAT to the gateway / device interworking module (S440).
  • the gateway / device interworking module sends a connection status check event setting / change request message including an event setModObjPLAT which is event setting / change information_PLAT to the M2M gateway / device 403 (S450).
  • the platform interworking module of the gateway / device receiving the connection status check event setting / change request message including the eventSetModObjPLAT transmits the contents to the management / monitoring module (S460), and the management / monitoring module sends eventMgmtObjGD which is event management information_GD. Create / change information such that the contents shown in Table 4 are stored in the DB (S470).
  • EventMgmtObjGD Attribute Explanation application ID
  • Application ID requesting a connection health check event
  • EventID Identification Information for Connection Status Check Events Cycle How often to send link health check events Allowable delay time Delayed Transmission Time of Connection Status Check Events
  • Event notification time The time at which the connection status check event was recently reported.
  • the event set by the specific M2M application 401 provides the eventSetModObjAPP to the M2M platform 402 is managed by the eventMgmtObjPLAT in the M2M platform 402, which in turn causes the M2M platform 402 to execute the eventSetModObjPLAT.
  • eventMgmtObjGD is stored to manage the event notification process.
  • the M2M gateway / device notifies the M2M platform of the event, and the M2M platform also determines whether the event is notified according to the event management information_PLAT or the event has not been notified for a predetermined time. Provided to M2M applications.
  • the management / monitoring module of the M2M gateway / device 503 generates event information to transmit the set event to the M2M platform 502 every event notification period set in the event management information_GD (eventMgmtObjGD) (S510).
  • the event information generated and transmitted by the management monitoring module is event information_GD (eventObjGD) and may be configured as shown in Table 5.
  • Event info_GD Attribute Explanation Gateway / device_ID ID (SCL ID) of the gateway / device that sends the connection status check event.
  • application ID List List of application IDs associated with this connection status check event EventID Identification Information for Connection Status Check Events Notification time Connection Status Check Event Notification Time
  • the event information_GD of Table 5 includes a gateway / device ID, an application ID list, and a notification time.
  • the application ID list means that the IDs of the corresponding applications are provided as a list when there are a plurality of applications to notify the event.
  • Notification time may optionally be included. That is, the notification time may be generated by the M2M gateway / device 503, and in another embodiment, the event information may be provided to the M2M platform 502 without the notification time to directly generate the time when the M2M platform is notified.
  • the management / monitoring module delivers the event information of Table 5 to the platform interworking module (S520), and the platform interworking module provides the received event information to the M2M platform 502 (S530). That is, S502 is a process of sending a connection status check event from the platform interworking module to the M2M platform. Thereafter, the management / monitoring module updates the latest connection state check event notification time of event management information_GD (eventMgmtObjGD) of Table 4 to the time when the platform is notified (S540). Thereafter, the M2M platform 502 and the M2M application 501 share information on occurrence or non-occurrence of an event according to the previously set or changed application notification policy.
  • event management information_GD event management information_GD
  • the management / monitoring module checks a period for notifying the event for each application. If it is time to notify the event, if there is an event scheduled to be notified within the event notification time + allowable delay time of the application, only the event to be notified is added to the event waiting list and not notified. Notify and update the notification time of the two applications together. That is, the notification may be performed according to a predetermined notification period, and an event generated before the notification period may be stored and stored until the corresponding period is reached.
  • FIG. 6 illustrates a process in which a gateway or a device performs event notification for two or more applications according to an embodiment of the present specification.
  • the gateway / device performs event notification for the A and B applications, the A application has a 7 minute period and a 2 minute allowable delay time, and the B application has a 5 minute period and a 1 minute allowable delay time.
  • the application A starts notification of the connection confirmation event
  • the application B starts notification of the connection confirmation event at 0:10.
  • the application A needs to perform event notification at 0:14, but it is confirmed that the event notification (0:15) of the application B is scheduled before the allowable delay time of 0:16. Therefore, after adding the event notification of the A application to the event waiting list, event notifications of the A and B applications are performed at 0:15.
  • the B application at 0:20, the A application at 0:22, and the B application at 0:25 each perform event notification.
  • the application A needs to perform event notification at 0:29, and confirms that the event notification (0:30) of the application B is scheduled before 0:31, which is an acceptable delay time. Therefore, after adding the event notification of the A application to the event waiting list, event notification of the A and B applications is performed at 0:30.
  • event transmission / reception can be performed more effectively by sending a plurality of connection state confirmation event notifications for each application together with an event within a predetermined delay range.
  • the application notification policy means a policyType set in eventSetModObjAPP or eventMgmtObjPLAT as described in Tables 1 and 2 above.
  • the gateway / device notifies the platform of the event or not, the policy is how the platform will notify the application.
  • identification numbers of the events to be notified may be charged separately to distinguish them from other types of events.
  • a function of distinguishing the connection status check event from other connection status check events may be provided. For example, when there is a connection status check event checked in units of time and a connection status check event checked in units of days, separate event identification numbers may be charged for each cycle.
  • FIG. 7 is a diagram illustrating an example in which the platform performs event notification to an application according to an application notification policy according to an embodiment of the present specification.
  • the application waits for a predetermined time and notifies the application.
  • the M2M gateway / device 703 fails in event notification (S710). Failure to notify an event can occur for a variety of reasons, such as a network error or a gateway / device device error.
  • the M2M platform 702 checks that the event is not notified because the delayed transmission time is exceeded during the event notification situation monitoring (S720).
  • the M2M platform 702 notifies the M2M application 701 that the connection status confirmation event for the specific gateway / device is not notified according to the policyType (S730). Subsequently, subsequent work may be performed according to the instruction of the M2M application 701.
  • 8 is a diagram illustrating an example in which the platform performs event notification to an application according to an application notification policy according to another embodiment of the present specification. 8 illustrates a method of notifying an application when a connection state confirmation event is received.
  • the M2M gateway / device 803 notifies the event (S810).
  • the M2M platform 802 confirms that the event has been notified during the event notification situation monitoring (S820).
  • the M2M platform 802 notifies the M2M application 801 that the connection status confirmation event for the specific gateway / device has been notified according to the policyType (S830). Subsequently, subsequent operations may be performed according to the instructions of the M2M application 801.
  • 9 is a diagram illustrating an example in which the platform performs an event notification to an application according to an application notification policy according to another embodiment of the present specification. 9 illustrates a method of notifying an application of a notification of a connection status checking event at regular intervals.
  • the M2M gateway / device 903 continuously notifies the event (S910 to S920).
  • the M2M platform 902 confirms that the cycle to notify the application during the event notification situation monitoring (S930).
  • the M2M platform 902 notifies the M2M application 901 that the connection status confirmation event notification for the specific gateway / device has been performed for a predetermined period according to the policyType (S940). Subsequently, subsequent work may be performed according to the instruction of the M2M application 901.
  • the eventSetModObjAPP in Table 1 and the eventMgmtObjPLAT in Table 2 may include an item called notifyingPeriod that sets a notification period instead of waitingCount.
  • FIG. 10 illustrates a case in which an application requests an inquiry of a connection status confirmation event from a platform according to an embodiment of the present specification.
  • connection status check event inquiry request is as follows.
  • the application interworking module of the M2M platform receives a connection status check event inquiry request for a specific gateway or device from a plurality of applications (S1010).
  • Information included in the inquiry request message of S1010 is an event inquiry_APP (eventViewAPP), and may be configured as shown in Table 6.
  • Event Lookup_APP Attribute Explanation application ID Application ID requesting a lookup of the connection status check event.
  • EventID Identification Information for Connection Status Check Events Gateway_or_device Whether the destination for the connection status check event is a gateway or a device Gateway / device_ID Destination ID (SCL ID) to which to send the connection status check event. Gateway / device_address Destination address to send link health check event to
  • the application interworking module delivers the same information as the embodiment of Table 6 to the event management module (S1020).
  • the received event management module delivers information consisting of some items of eventMgmtObjPLAT in Table 2 or eventMgmtObjPLAT in Table 2 to the application interworking module based on the received information (S1040), and the application interworking module uses the M2M application ( In step S1050, the event information is transmitted to the inquiry request.
  • FIG. 11 is a diagram illustrating a case in which an application requests deletion of a connection status confirmation event from a platform according to an embodiment of the present specification.
  • the M2M application 1101 transmits a deletion request message of a connection status confirmation event for a specific gateway / device to an application interworking module of the M2M platform 1102 (S1110).
  • the request message transmitted that is, the connection status check event deletion request message for a specific gateway or device received from a plurality of applications by the application interworking module of the M2M platform S1102 includes an eventDelAPP for deleting an event. It may include information of the configuration, such as.
  • the configuration of Table 7 is an embodiment, and a part of the configuration of Table 7 may be excluded for implementation or additional information may be added. Table 7 lists the attributes of the object of eventDelAPP that the application provides to the platform.
  • EventDel Attribute Explanation application ID
  • the application ID requesting the deletion of the connection status check event.
  • EventID Identification Information for Connection Status Check Events Gateway_or_device Whether the connection status check event destination to be deleted is a gateway or a device Gateway / device_ID Destination ID (SCL ID) to which to send the connection status check event. Gateway / device_address Destination address to send link health check event to
  • the application interworking module transmits information of the eventDel received in S1110 to the event management module (S1120).
  • the event management module provides event deletion information, eventDel, to the gateway / device interworking module so that the gateway / device can terminate the event notification (S1130).
  • This is information to be delivered to the corresponding gateway or device, and consists of information necessary to stop event notification, and can be implemented as shown in Table 7.
  • the information received in S1110 may be used as is, in part, or in part of information of eventMgmtObjPLAT.
  • the gateway / device interworking module transmits information related to the event to be deleted to the corresponding gateway / device (S1140).
  • the platform interworking module of the gateway / device which has received this transfers the corresponding contents to the management / monitoring module (S1150), and the management / monitoring module deletes the contents related to the corresponding application (S1160). Then, after transmitting the deleted result to the platform interworking module and sends a response from the platform interworking module to the platform (S1170).
  • the gateway / device interworking module of the M2M platform 1102 which has received the response transmits to the monitoring module and the event management module if the response is successful (S1180).
  • the received monitoring module stops monitoring the corresponding content and the event management module deletes the corresponding content from the DB (S1190), and sends the result to the application interworking module and sends the result to the M2M application 1101 (S1195).
  • FIG. 12 is a diagram illustrating a process of managing connection between entities according to one embodiment of the present specification.
  • 4 to 11 illustrate a process of setting, changing, or deleting connection management, or inquiring of a status of connection management by an M2M application.
  • the M2M application 1201 requests the M2M platform core SC 1202 to set / change / view / delete an event cycle and a policy for a specific gateway / device (S1210).
  • the M2M platform 1202 creates and records event management information in the DB or changes related to the change / delete / query request in response to a request for setting / modifying / viewing / deleting an event cycle and a policy for a specific gateway / device. (S1220). Then, according to the request, the event period for a specific gateway / device is set or a change / deletion is requested to the corresponding M2M gateway / device 1203 and 1204 (S1230).
  • the M2M gateway / device 1203 and 1204 Notify the event to the M2M platform 1202 according to the set / changed event (S1240), M2M platform 1202 performs the event monitoring (S1250), the event according to the monitoring policy (previous policyType of Table 1, 2, etc.)
  • the M2M application 1201 may be notified as soon as it is notified by the M2M gateway / devices 1203 and 1204, or may be notified to the M2M application 1201 when the event is not informed for a predetermined period of time (S1260).
  • the apparatus in FIGS. 13, 14, and 15 collectively refers to an M2M gateway or an M2M device.
  • FIG. 13 is a diagram illustrating a process of managing connection of another device in an M2M application according to one embodiment of the present specification.
  • Event management information for connection management of the M2M gateway or M2M device is transmitted to the M2M platform (S1310). This may include sending event management information to the M2M platform instructing setting, changing, querying or deleting an event for connection management of the M2M gateway or the M2M device.
  • the event management information includes the eventSetModObjApp described in Table 1, the eventViewApp in Table 6, or the eventDel in Table 7.
  • a result of event notification of the M2M gateway or M2M device is received (S1330). This includes receiving a processing result of the event management information from the M2M platform. Then, according to the result of the event notification, the M2M application performs the subsequent work (S1340). If the event is to be changed, step S1310 is performed again. If the event notification is to be continued, step S1330 is performed.
  • the event management information of FIG. 13 is controlled by a connection management service capability, which is a service capability provided by the M2M platform. Also, as shown in Table 1, the event management information is stored in the M2M gateway or the M2M gateway.
  • the M2M device may include information about a period for notifying the event and a policy related to notification or non notification of the event.
  • FIG. 14 is a diagram illustrating a process of managing connection of another device according to an instruction or request of an M2M application in an M2M platform according to one embodiment of the present specification.
  • the M2M platform receives event management information for connection management of the M2M gateway or M2M device from the M2M application (S1410). That is, the method may include receiving event management information from the M2M application instructing setting, changing, inquiring, or deleting an event for connection management of the M2M gateway or the M2M device.
  • the event management information is recorded, changed or deleted in the database according to the above instruction (S1420). Recording, changing, and deleting may be eventMgmtObjPLAT in Table 2 or eventDel in Table 7. If the instruction from the M2M application is event setting, change, or deletion (S1430), the M2M platform instructs the M2M gateway or M2M device to set, change, or delete an event (S1440).
  • the M2M platform transmits event information instructing the M2M gateway or the M2M device to set, change or delete an event to the M2M gateway or the M2M device.
  • the M2M platform may transmit the eventSetModObjPLAT of Table 3 to indicate setting or change, or the eventDel of Table 7 to the M2M gateway or device to delete an event.
  • the M2M platform receives a processing result from an M2M gateway or an M2M device (S1450).
  • the processing result is processing of event setting, change, and deletion, and also includes an event that is notified about setting / change of the event. That is, when the event management information indicates setting or change of an event, the processing result includes event notification of the M2M gateway or the M2M device.
  • the M2M platform transmits the processing result to the M2M application (S1460).
  • the notification of the event held in the meantime is transmitted as the processing result to the M2M application (S1460).
  • the event management information of FIG. 14 is controlled by a connection management service capability, which is a service capability provided by the M2M platform. Also, as shown in Table 2, the event management information is represented by the M2M gateway or the M2M gateway.
  • the M2M device may include information about a period for notifying the event and a policy related to notification or non notification of the event.
  • the event information is controlled by a connection management service function provided by the M2M gateway or the M2M device.
  • the configuration of the M2M platform performing the process of FIG. 14 is as described above with reference to FIG. 3, in which event management information for instructing setting, changing, inquiring, or deleting an event for connection management of an M2M gateway or an M2M device is received from an M2M application.
  • An application interworking module for receiving, a connection management module for recording, changing, or deleting the event management information in a database according to the instruction; a monitoring module for monitoring an event transmitted by the M2M gateway or an M2M device; and the event management information.
  • the event information instructing the M2M gateway or the M2M device to set, change, or delete the event is transmitted to the M2M gateway or the M2M device, and the M2M gateway or To the M2M device
  • Receiving the processing result emitter consists of the monitoring module and gateway / interworking device module that provides information to the application interlocking modules.
  • 15 is a diagram illustrating a process of managing a connection in a device connected to an M2M platform according to one embodiment of the present specification.
  • the apparatus of FIG. 15 includes an M2M Gateway or M2M Device.
  • the device receives event information indicating setting, change, or deletion of an event from the M2M platform (S1510).
  • the event information may be eventSetModObjPLAT of Table 3 described above or eventDel of Table 7 to delete an event.
  • the device In case of setting / changing an event (S1520), the device notifies the event according to a period determined by the M2M platform (S1540). On the other hand, if the deletion, the event notification is stopped (S1530).
  • the event information is controlled by a connection management service function of an apparatus, that is, an M2M gateway or the M2M device, and includes information on a notification period of the event.
  • the configuration of the M2M gateway or the M2M device performing the process of FIG. 15 receives the event information indicating the setting, change, or deletion of the event from the M2M platform as described above with reference to FIG. And a platform interworking module for transmitting to the M2M platform and a management / monitoring module for managing and monitoring the event to notify the M2M platform of the event according to the setting and the change, when the event information indicates the setting or the change of the event. do.
  • gateways and devices periodically send connection status events to the platform, and the platform monitors the connection status check events of the corresponding gateways and devices, and displays gateway and device information for which connection status check events are not received. By notifying related applications, the connection status of the gateway and the device can be managed.
  • the M2M gateway and the device may periodically transmit a connection status check event to the platform, thereby performing other events delivered from the gateway and the device. It is effective to manage reliably.
  • connection state confirmation notification policy of the gateway and the device through the M2M platform in the relevant application, it is possible to manage the state of the gateway and the device more effectively by setting the policy according to the network situation or the characteristics of the gateway and the device. That is, if the event reception is important, such as an always-on device or an e-health terminal that always accesses the Internet, it will be necessary to check the connection status in a policy.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne un procédé et un appareil de gestion d'une connexion entre des objets de communication machine à machine (M2M) basée sur un événement de confirmation d'état de connexion. Selon un mode de réalisation de l'invention, un procédé de gestion d'une connexion dans une plate-forme M2M comprend: une étape de réception, d'une application M2M, d'informations de gestion d'événements qui instruisent l'installation, la conversion, l'interrogation ou la suppression d'un événement pour la gestion de la connexion d'une passerelle M2M ou d'un dispositif M2M; une étape d'enregistrement, de conversion ou de suppression des informations de gestion d'événements selon les instructions; une étape de transmission à la passerelle M2M ou au dispositif M2M des informations de gestion d'événements instruisant la configuration, la conversion ou la suppression de l'événement lorsque ces informations instruisent effectivement la configuration, la conversion ou la suppression de l'événement; et une étape de réception d'un résultat de traitement de la passerelle M2M ou du dispositif M2M, et de transmission du résultat de traitement à l'application M2M. Le résultat de traitement comprend une notification d'événement de la passerelle M2M ou du dispositif M2M lorsque les informations de gestion d'événements instruisent la configuration ou la conversion de l'événement. Les informations de gestion d'événements sont commandées par une fonctionnalité de service de gestion de connexion fournie au niveau de la plate-forme M2M par la passerelle M2M ou le dispositif M2M.
PCT/KR2012/003284 2011-05-03 2012-04-27 Procédé et un appareil de gestion d'une connexion entre des objets de communication basée sur un événement de confirmation d'état de connexion Ceased WO2012150778A2 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR20110041820 2011-05-03
KR10-2011-0041820 2011-05-03
KR1020110055982A KR20120124345A (ko) 2011-05-03 2011-06-10 연결 상태 확인 이벤트에 기반하여 m2m 통신 개체간 연결을 관리하는 방법 및 장치
KR10-2011-0055982 2011-06-10

Publications (2)

Publication Number Publication Date
WO2012150778A2 true WO2012150778A2 (fr) 2012-11-08
WO2012150778A3 WO2012150778A3 (fr) 2013-01-17

Family

ID=47108112

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2012/003284 Ceased WO2012150778A2 (fr) 2011-05-03 2012-04-27 Procédé et un appareil de gestion d'une connexion entre des objets de communication basée sur un événement de confirmation d'état de connexion

Country Status (1)

Country Link
WO (1) WO2012150778A2 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014129802A1 (fr) * 2013-02-19 2014-08-28 엘지전자 주식회사 Procédé pour modifier un paramètre de service m2m et appareil associé
WO2015046960A1 (fr) * 2013-09-27 2015-04-02 엘지전자 주식회사 Procédé de délivrance d'un message de notification dans un système m2m et dispositifs associés
KR20170055530A (ko) * 2014-09-17 2017-05-19 콘비다 와이어리스, 엘엘씨 서비스 레이어를 통해 제3자 서비스들에 대한 액세스를 가능하게 하는 시스템들 및 방법들
CN116471575A (zh) * 2015-10-23 2023-07-21 瑞典爱立信有限公司 机器对机器装置的操作状态的建立

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001306511A (ja) * 2000-04-25 2001-11-02 Pfu Ltd マシン情報の収集方法およびマシン情報の収集装置ならびにその記録媒体
KR101007739B1 (ko) * 2008-12-03 2011-01-13 주식회사 케이티 Fota 서비스 제공 방법 및 그 시스템
KR101048854B1 (ko) * 2009-01-19 2011-07-13 주식회사 케이티 M2m 어플리케이션의 가입자 트래픽 데이터에 대한 서비스제어 방법 및 그 시스템
US9560140B2 (en) * 2009-09-29 2017-01-31 Qualcomm Incorporated Signaling identification of machine to machine devices and services

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014129802A1 (fr) * 2013-02-19 2014-08-28 엘지전자 주식회사 Procédé pour modifier un paramètre de service m2m et appareil associé
CN104995889B (zh) * 2013-02-19 2019-01-01 Lg电子株式会社 用于修改m2m服务设置的方法及其装置
US9800999B2 (en) 2013-02-19 2017-10-24 Lg Electronics Inc. Method for modifying M2M service setting and apparatus therefor
US9723429B2 (en) 2013-09-27 2017-08-01 Lg Electronics Inc. Method for delivering notification messages in M2M system and devices for same
US10051404B2 (en) 2013-09-27 2018-08-14 Lg Electronics Inc. Method for delivering notification message in M2M system and devices for same
WO2015046960A1 (fr) * 2013-09-27 2015-04-02 엘지전자 주식회사 Procédé de délivrance d'un message de notification dans un système m2m et dispositifs associés
KR20170055530A (ko) * 2014-09-17 2017-05-19 콘비다 와이어리스, 엘엘씨 서비스 레이어를 통해 제3자 서비스들에 대한 액세스를 가능하게 하는 시스템들 및 방법들
US10931762B2 (en) 2014-09-17 2021-02-23 Convida Wireless, Llc Systems and methods for enabling access to third party services via a service layer
US11240321B2 (en) 2014-09-17 2022-02-01 Convida Wireless, Llc Systems and methods for enabling access to third party services via a service layer
US11616851B2 (en) 2014-09-17 2023-03-28 Convida Wireless, Llc Systems and methods for enabling access to third party services via a service layer
US11882195B2 (en) 2014-09-17 2024-01-23 Convida Wireless, Llc Systems and methods for enabling access to third party services via a service layer
US12301681B2 (en) 2014-09-17 2025-05-13 Convida Wireless, Llc Systems and methods for enabling access to third party services via a service layer
CN116471575A (zh) * 2015-10-23 2023-07-21 瑞典爱立信有限公司 机器对机器装置的操作状态的建立

Also Published As

Publication number Publication date
WO2012150778A3 (fr) 2013-01-17

Similar Documents

Publication Publication Date Title
WO2020071797A1 (fr) Améliorations apportés à des réseaux de télécommunications et relatives à ceux-ci
WO2013025085A2 (fr) Appareil et procédé permettant de prendre en charge un nuage de famille dans un système informatique en nuage
WO2021071032A1 (fr) Procédé et appareil de contrôle d'accès au dispositif pour l'internet des objets
WO2012134080A2 (fr) Procédé et appareil pour la séparation afin de mettre à niveau un logiciel à distance dans une communication m2m
WO2020019405A1 (fr) Procédé, dispositif, appareil de surveillance de base de données et support d'informations informatique
WO2016126021A1 (fr) Procédé et appareil de traitement de requête pour l'arrêt de réception de notification dans un système de communication sans fil
WO2021085984A1 (fr) Procédé par lequel un nœud upf comprenant une pluralité d'instances upf exécute une surveillance de qos, et nœud upf exécutant ce procédé
WO2023059157A1 (fr) Procédé et appareil pour surveiller une utilisation de données dans un système de communication sans fil
WO2012150778A2 (fr) Procédé et un appareil de gestion d'une connexion entre des objets de communication basée sur un événement de confirmation d'état de connexion
WO2016195199A1 (fr) Procédé de traitement de requête par un canal d'interrogation dans un système de communication sans fil et appareil associé
WO2022086000A1 (fr) Dispositif nœud d'accès sans fil et procédé d'interface mis en œuvre par un dispositif nœud d'accès sans fil
WO2012099402A2 (fr) Procédé et appareil de communication téléphonique utilisant un réseau domestique
WO2021125502A1 (fr) Système de fourniture de service en nuage basé sur des conteneurs et procédé associé
KR20120124345A (ko) 연결 상태 확인 이벤트에 기반하여 m2m 통신 개체간 연결을 관리하는 방법 및 장치
WO2015062052A1 (fr) Procédé d'interrogation et de programmation de données m2m, dispositif d'interrogation et de programmation, et système
WO2013129804A1 (fr) Procédé, système, et support d'enregistrement pour analyser l'ensemble de règles de réduction de charge d'un réseau radio
WO2020009537A1 (fr) Procédé et dispositif de gestion de ressources
WO2014189324A1 (fr) Procédé et appareil pour gérer des réseaux d'accueil sans fil
WO2020166927A1 (fr) Procédé et dispositif d'abonnement et de notification
WO2019194412A1 (fr) Appareil de réseau et son procédé de commande
WO2020062870A1 (fr) Procédé de balayage de canal, télévision intelligente et support de stockage lisible par ordinateur
WO2017082506A1 (fr) Procédé de traitement d'une demande d'arrêt de réception de notification dans un système de communication sans fil, et dispositif associé
WO2018236137A1 (fr) Procédé de traitement de message de requête dans un système m2m et dispositif associé
WO2015088268A1 (fr) Procédé de traitement de défaillance de dispositif de réseau dans un environnement de réseautage défini par logiciel (sdn)
WO2015080512A1 (fr) Procédé pour traiter un événement entre un dispositif de commande et un dispositif de réseau

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12779657

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12779657

Country of ref document: EP

Kind code of ref document: A2