KR101986851B1 - A method for searching information of M2M systems and apparatus therefor - Google Patents

A method for searching information of M2M systems and apparatus therefor Download PDF

Info

Publication number
KR101986851B1
KR101986851B1 KR1020130017712A KR20130017712A KR101986851B1 KR 101986851 B1 KR101986851 B1 KR 101986851B1 KR 1020130017712 A KR1020130017712 A KR 1020130017712A KR 20130017712 A KR20130017712 A KR 20130017712A KR 101986851 B1 KR101986851 B1 KR 101986851B1
Authority
KR
South Korea
Prior art keywords
discovery
resource
filter condition
m2m
method
Prior art date
Application number
KR1020130017712A
Other languages
Korean (ko)
Other versions
KR20140103786A (en
Inventor
이승권
장덕문
Original Assignee
주식회사 케이티
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
Application filed by 주식회사 케이티 filed Critical 주식회사 케이티
Priority to KR1020130017712A priority Critical patent/KR101986851B1/en
Publication of KR20140103786A publication Critical patent/KR20140103786A/en
Application granted granted Critical
Publication of KR101986851B1 publication Critical patent/KR101986851B1/en

Links

Images

Abstract

A method and apparatus for searching M2M resources are provided. The method includes the steps of receiving a discovery resource processing according to a specific filter condition (filterCriteria), performing a discovery operation according to a filter condition to generate a URI list as a result, and a URI list according to the filter condition discovery < / RTI > resources.

Description

[0001] METHOD AND APPARATUS FOR RETRIEVING RESOURCES IN M2M COMMUNICATIONS [0002]

The present invention relates to a method and apparatus for retrieving information on M2M resources of a plurality of M2M platforms in an M2M (Machine to Machine Communication) network.

"Machine-to-machine communication" or M2M, "Machine type communication" or "Smart Device communication" or "Machine oriented communication") means that all communication methods Refers to a communication method.

The European Telecommunications Standards Institute (ETSI) has announced the ETSI TS 102 690 V1.1.1 (hereinafter "structure") functional structure for providing M2M communication in October 2011.

The M2M platform (server) stores information when the information is transmitted from a device, a gateway, or a device connected to the gateway using container resources defined according to the structure of the existing ETSI M2M standard.

The M2M service provider builds and manages the M2M platform. According to the diversification of M2M service providers, communication between a plurality of M2M network domains, that is, N-N communication, has been developed based on each M2M platform managed by each service provider, and efficient resource information search method is required in such N-N communication.

In order to solve the above-described problems, the present invention provides a method and apparatus for efficiently storing resource information by storing a processing result of a discovery resource in N-N communication.

According to an embodiment of the present invention, there is provided a method for processing a discovery resource according to a specific filter condition (filterCriteria) Performing a discovery operation according to the filter condition to generate a URI list as a result; And storing the URI list according to the filter condition as a discovery resource.

The discovery resource may be generated as a dependent resource of a discovery collection resource. In addition, the discovery resource may include an attribute indicating the requested filter condition and an attribute indicating a result of performing the discovery, respectively. The filter condition may be stored as a requestedSearchString attribute. Also, the URI list according to the result of the discovery may be stored as a discovery result attribute. The discovery resource may further include at least one of attributes indicating a frequency and a frequency of a discovery request for the filter condition.

According to another embodiment of the present invention, when a discovery resource process is requested according to a specific filter condition (filterCriteria), a discovery operation is performed according to the filter condition to generate a URI list as a result, and the URI list Is stored as a discovery resource.

According to the present invention, since the frequency of repetition of the same discovery is increased, the performance of the server can be prevented from deteriorating and the network traffic can be reduced by storing the discovery resource processing result.

In addition, according to the present invention, by storing the discovery resource processing result, it is possible to promptly respond to the same discovery resource request without performing separate discovery operation processing, thereby improving the efficiency of the discovery operation and reducing the device load of the server receiving the discovery request, .

In addition, there is an effect that discovery resources can be managed more efficiently by setting a time for storing the result of the discovery processing according to the number of times and the period of the request for the discovery resource.

1 is a diagram showing a configuration of an M2M system.
2 is a diagram for explaining a configuration of a discovery resource.
FIG. 3 is a diagram for explaining a process according to a discovery request.
4 is a diagram showing the configuration of an M2M system including a plurality of network domains.
5 is a diagram for explaining a discovery process in an NN communication environment.
FIG. 6 is a diagram illustrating a structure of a discovery collection resource according to an embodiment of the present invention.
FIG. 7 illustrates a structure of a discovery resource according to an embodiment of the present invention. Referring to FIG.
FIG. 8 is a diagram for explaining a discovery resource inquiry procedure according to another embodiment of the present invention.
9 is a diagram for explaining a procedure of creating, updating, and deleting a discovery resource according to another embodiment of the present invention.
FIG. 10 is a diagram for explaining a discovery procedure according to another embodiment of the present invention.

Hereinafter, some embodiments of the present invention will be described in detail with reference to exemplary drawings. It should be noted that, in adding reference numerals to the constituent elements of the drawings, the same constituent elements are denoted by the same reference symbols as possible even if they are shown in different drawings. In the following description of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear.

In describing the components of the present invention, terms such as first, second, A, B, (a), and (b) may be used. These terms are intended to distinguish the constituent elements from other constituent elements, and the terms do not limit the nature, order or order of the constituent elements. When a component is described as being "connected", "coupled", or "connected" to another component, the component may be directly connected or connected to the other component, Quot; may be "connected," "coupled," or "connected. &Quot;

Embodiments of the present invention will be described with reference to object communication. Object communication is variously divided into machine-to-machine communication (M2M), Machine Type Communication (MTC), Internet of Things (IOT), Smart Device Communication (SDC), and Machine Oriented Communication And will be described in the following description with reference to M2M. However, this description is not limited to M2M, but is applicable to all systems and structures providing inter-device communication, i.e., object communication, and communication occurring in these systems.

In addition, such object communication can be applied to various fields including Smart Meter, e-Health, Connected Consumer, City Automation, and Automotive Application .

An M2M object or device herein may be an M2M device (e.g., an M2M standard device (D), an M2M non-standard device (d) or an M2M partial standard device (D ' G) or an M2M network server.

1 is a diagram illustrating an example of an M2M service architecture to which the present invention is applied.

Referring to FIG. 1, an M2M service structure of an M2M standard structure includes, for example, a case 1, a case 2, a legacy case 1, a legacy case 2, a legacy case 3, (Legacy case 3) and the like can be considered.

The M2M service architecture consists of the M2M device domain and the network / application domain or M2M server platform to provide the object intelligence communication service.

The network / application domain includes M2M applications, M2M applications, Core Network, and M2M SC, which access or provide service logic to M2M Service Capabilities (M2M Service Capabilities).

On the other hand, an M2M device domain includes an M2M device or an M2M gateway. M2M devices and M2M gateways also include M2M applications, and may further include M2M SC.

If the M2M device includes an M2M SC, it may interwork and interconnection in the network / application domain via the included M2M SC.

In addition, if the M2M device does not include the M2M SC, it can interworking and interconnection in the network / application domain through the interface with the M2M SC included in the M2M gateway.

The M2M device can operate the M2M application to interoperate and interconnection in the network / application domain through the M2M service capability (Service Capabilities: SC) of the M2M device or the M2M gateway to utilize the functions of the network domain.

The SC may include one or more of xAE, xGC, xRAR, xCS, xREM, xSEC, xHDR, xTM, xTM, xIP, xCB or xTOE, where x is N for a network, G for a gateway, D can be. That is, xIP can be NIP, GIP, or DIP. The xSEC described below is a security capability, which may be NSEC, GSEC or DSEC.

The Service Capability Layer (SCL) of the M2M device or the M2M gateway forms a specific interface with the Service Capability Layer (SCL) of the network domain to inter-operate and inter-operate.

In addition, the SCs in the network domain can interface with one or more core networks. In this case, the functions of the core network can be utilized through known interfaces according to other existing standards.

To this end, reference points of mIa, mId, and dIa are defined as the interface between the network domain and the device and gateway domains according to the M2M standard structure.

mIa is a reference point used in the network domain, and is an interface standard between an NSCL (M2M Service Capability Layer in the network), which is a service capability layer provided by the M2M platform, and a Network Application (NA), which is a network application.

mId is the interface specification between the NSCL of the network domain and the device / gateway service capability layer D / G SCL (DSCL or GSCL) of the device / gateway domain. That is, mId is an interface standard applied between the NSCL of the network domain provided by the M2M platform and the DSCL (M2M Service Capabilities in the M2M Device), which is a service capability layer of the device.

dIa is a reference point used in the M2M device / gateway domain. It is an interface between a device service capability layer (DSCL) and a device application (DA) provided by the M2M device, a gateway service capability layer (GSCL ), A gateway application (GA) interface, and an interface specification of GSCL and DA provided by the M2M gateway.

Case 1 shows an M2M device (D) 110 including an M2M service capability (SC) 113 and an M2M application 111. The M2M device (D) 210 may interface with the NSCL of the network domain 190 using the mId reference point.

Case 2 shows an M2M device (D ') 130 including the M2M application 131 but including the M2M SC. The M2M device (D ') 130 may rely on the M2M SC (173) of the M2M gateway (G) 170 using the dIa reference point instead of the M2M SC.

Legacy cases 1 to 3 (Legacy cases 1 to 3) correspond to a case where the device is a legacy device (d) 150, which is a nonstandard standard device that does not include the M2M service as well as the M2M service capability. In this case, the legacy device d may interworking and interconnection in the network domain 190 via Interworking Proxy capability (xIP), which is an embodiment of the SC.

Where x may be N for a network, G for a gateway, or D for a device. That is, xIP can be NIP, GIP, DIP.

The xIP can discover the structure of the M2M area network and create an M2M resource structure representing the M2M area network structure in the SCL. When the M2M area network structure changes, the M2M resource structure can be managed to reflect this.

Legacy case 1 may allow non-standard device (d) 150 to interwork and interconnection in network domain 290 through the NIP of the network domain.

Also, legacy case 2 may allow interoperable and interconnection of non-standard device (d) 150 in network domain 190 via the GIP of M2M gateway.

Legacy case 3 may also interworking and interconnection the non-standard device (d) 150 in the network domain 190 via the DIP of the M2M device (D).

In a single NSCL environment as shown in FIG. 1, an issuer, such as, for example, an application or service capability, that wants to retrieve information about a particular resource to obtain it, may request a discovery resource in the NSCL .

Because M2M NSCL has a large number of resources stored therein, application or service capabilities use filter conditions to reduce the scope of discovery search operations at this time. The filter condition is expressed by, for example, a searchStrings attribute, and the filter condition is used in the operation processing for the discovery resource request in the NSCL.

In the NSCL, a discovery operation process is performed to generate an address of a resource conforming to the filter condition, for example, a URI (Uniform Resource Identifier) list, and the result is transmitted to the requester. At this time, the URI list according to the result of the discovery operation is discarded without being stored in the discovery resource or the like.

Figure 2 shows the structure of the discovery resource.

Referring to FIG. 2, since the result of the discovery operation process is not stored in the discovery resource, it is understood that the discovery resource does not include the attribute and the sub-resource.

The discovery resource is used to search for resources within the service capability (SCL). That is, according to the discovery request, as described above, the URI list of the resources matching the filter condition (filterCriteria) among the resources included in the <sclBase> resource of the service capability (SCL) is retrieved and delivered to the requester, and the retrieved URI list is discarded .

3 is a diagram illustrating a process according to a discovery request for resource search.

The issuer 310 first generates a request message in the form of &quot; <sclBase> / discovery &quot; using the RETREVE command to provide the hosting SCL 320 with a discovery resource request (S351).

In this case, the discovery resource processing, that is, the filter condition for retrieving (filterCriteria), is provided by the issue word 310 as parameters such as, for example, the searchStrings attribute.

The hosting SCL 320 verifies whether the request message of the issuer 310 and the included parameters are valid, and generates a URI list matching the filter condition (filterCriteria) (S353).

Then, the hosting SCL 320 delivers the URI list generated by the Discovery Response message to the requestor 310 (S355). At this time, if the generated URI list size is larger than the size requested by the requestor 310, the hosting SCL 320 reduces the request size to the request size and delivers the reduced size to the requestor 310.

FIG. 4 is a diagram for explaining an integrated service capability layer (SCL) for integrally managing NSCL shared data according to the present invention.

Referring to FIG. 4, the M2M system structure includes a plurality of network domains. In the communication between network domains, mIm is a service capability layer of the network domain provided by the M2M platform 190, Which is a service capability layer of the network domain provided by the platform 200. [

5 is a diagram for explaining a discovery process in an N-N communication environment.

Referring to FIG. 5, an NN communication environment structure in which a plurality of network domains are connected and communicated with each other is provided. NSCL 1 521 is an SCL possessing a weather resource. NSCL 2 523, NSCL 3 525, Lt; RTI ID = 0.0 &gt; 529 &lt; / RTI &gt;

Accordingly, the NSCL 1 521 receives a discovery request from the network application (NA) 531, the device application 533 and the service capability (DSCL / GSCL) 535 connected to the NSCL 1 521, A device application (DA) 513 or a service capability (DSCL / GSCL) 515 connected to the NSCL 3 525, for example, a discovery request from another network application (NA)

NSCL 1 521 is compared to receiving a discovery request only from network application (NA) 531, device application (DA) 533, and service capability (DSCL / GSCL) directly connected to NSCL 1 521, NSAC 3 525 and NSCL n 529 and another network domain 511 connected to each of them again, a device application 513 and a service capability 515 ), The same discovery request may frequently be repeated in a short time in the NN communication.

In this case, if the discovery operation result is discarded, the NSCL 1 (521) must perform the same discovery operation repeatedly, thereby increasing the server load. Also, as the number of platforms (NSCL) requesting weather resources increases, the load of NSCL 1 (521) increases.

Therefore, the result of the discovery operation process can be stored without being discarded for a predetermined time, and the result of the stored operation can be utilized if the same discovery request is repeated. The structure of the M2M resource can be defined as follows to store the discovery operation result.

FIG. 6 is a diagram illustrating a structure of a discovery collection resource according to an embodiment of the present invention. Referring to FIG.

To store the processing results of the discovery, the existing standard discovery resource is replaced by the discovery collection resource and the discovery resource <discovery>.

Therefore, in the configuration of the discovery resource according to the present invention, first, a discovery collection resource is generated.

The discovery collection resource represents a collection of discovery resources < discovery > as shown in Fig. The discovery collection resources may also include discovery resources and subscription resources as their subresources, as shown in Table 1 below.

subResource Multiplicity Desctription <discovery> 0..unbounded See clause 9.2.3.36.x Subscriptions One See clause 9.2.3.22

FIG. 7 illustrates a structure of a discovery resource according to an embodiment of the present invention. Referring to FIG.

According to the present invention, a discovery resource < discovery > is generated as a dependent resource of a discovery collection resource.

The < discovery > resource represents an instance according to the result of the discovery operation as shown in Fig. In addition, the <discovery> resource contains mandatory attributes and optional attributes as shown in [Table 2] below.

Attribute Name Mandatory / Optional Type Desctription accessRightID O RW See clause 9.2.2 Common attributes. creationTime M RO See clause 9.2.2 Common attributes. lastModifiedTime M RO See clause 9.2.2 Common attributes. requestedSearchString M RW SearchString of requested discovery requestedNumber OfSearchString M RW Requests for SearchString requestedIntervalOfSearchString M RW Request cycle for SearchString discoveryResult M RW Discovery processing result expirationTime M RW Discovery Indicates when to discard processing results defaultExirationTime M RW Default point of discard of Discovery results

In Table 2, the requested search string (requestedSearchString) attribute indicates the search string (SearchString) of the requested discovery, and the processing result of the discovery, that is, the retrieved URI list, is stored in the discovery result attribute. Here, the name of the requested search string (requestedSearchStrings) and the discovery result (discoveryResult) attribute can be replaced with other names such as a search string or a search result by way of example, but are not limited thereto.

It is effective to limit the storage period according to the number of times of the discovery request and the request period, for example, to secure the storage space and to allocate resources, rather than storing the result of the discovery process without time limitation. Therefore, referring to Table 2, attributes such as the requestedNumberOfSearchString attribute and requestedIntervalOfSearchString are provided.

The requested string number of requests (requestedNumberOfSearchString) property refers to the number of discovery requests for the search string (SearchString) and the search string request period (requestedIntervalOfSearchString) refers to the period of the discovery request for the search string (SearchString).

 Therefore, the time of discarding the discovery result of the search string (SearchString) can be determined using the requestedNumberOfSearchString property and / or the requestedIntervalOfSearchString property. The determined abandonment time can be stored, for example, in the expiration time attribute. The default expiration time (defaultExirationTime) property indicates the default value of the expiration time for the result of the discovery process. If the expiration time property value is not set separately, the default expiration time (defaultExirationTime) can be used to discard the discovery result .

FIG. 8 is a view for explaining a discovery resource inquiry procedure according to another embodiment of the present invention. FIG. 9 is a diagram for explaining a procedure of creating, updating and deleting a discovery resource according to another embodiment of the present invention .

Hereinafter, procedures for UPDATE, CREATE, and DELETE processing as well as RETRIEVE procedure will be described in the discovery resource operation processing procedure.

8, an issuer 810, such as an application (NA, DA, GA) or a service capability (SCL), generates a request message using a RETREIVE command, (SCL) 820 to the discovery resource processing (S851). At this time, the requester 810 provides a filter condition (filterCriteria) for discovery resource processing, for example, a searchString attribute through a request message.

Accordingly, the hosting SCL 820 generates a URI list corresponding to the search string (searchString) (S853). To this end, the hosting SCL 820 first searches the attributes of the discovery resource, which is a dependent resource of the discovery collection resource, in the requestSearxhString attribute, and searches for the discovery resource < RTI ID = 0.0 > discovery> is present. If there is a matching discovery resource, the URI list stored in the discovery result attribute of the corresponding discovery resource is output as a result of the discovery operation for the search string.

However, if there is no discovery resource corresponding to the filter condition, the discovery operation is performed with reference to FIG. 4 for the search string, and a URI list is generated according to the result. In this case, the discovery resource can be created as a dependent resource of the discovery collection resource based on the search string and the generated URI list. This will be described in detail later.

Then, the hosting SCL 820 transmits the generated URI list to the requester 810 through a discovery response message (S855).

Referring to FIG. 9, the requestor 910 may request one of UPDATE, CREATE, and DELETE of the discovery resource (S951). This request may be made, for example, by a network application (NA) managing the server or by an application (NA, DA, GA) or service capability (SCL) that has performed a discovery request (RETRIEVE).

Accordingly, the hosting SCL 920 updates, creates or deletes the discovery resource < discovery > corresponding to the filter condition (filterCriteria) included in the discovery update, generation and deletion request (S953) (S955). &Lt; / RTI &gt;

FIG. 10 is a diagram for explaining a discovery procedure according to another embodiment of the present invention.

Referring to FIG. 10, if the same requester or other requestor makes the same discovery request after storing the processing result of the discovery resource, it can refer to the stored URI list according to existing discovery processing and respond.

When the issuer 1010 requests the discovery resource to the hosting SCL 1020 in step S1051, the hosting SCL 1020 processes the discovery resource request in step S1053 and replies to the issuer 1010 with the URI listener ). Then, the hosting SCL 1020 stores the generated URI list as a discovery resource and sets a storage validity time (S1057).

The SCL 1020 searches the URI list stored in the discovery resource for the discovery resource to the issuing SCL 1020 and transmits the retrieved URI listener 1010 to the issuer 1010. [ (S1063).

According to the present invention, since the frequency of repetition of the same discovery is increased in the N-N communication environment, the performance of the server can be prevented and the network traffic can be reduced by storing the discovery resource processing result.

In addition, according to the present invention, by storing the discovery resource processing result, it is possible to promptly respond to the same discovery resource request without performing separate discovery operation processing, thereby improving the efficiency of the discovery operation and reducing the device load of the server receiving the discovery request, .

In addition, it is possible to manage the discovery resources more efficiently by setting the time for storing the results of the discovery processing according to the frequency and the cycle of the discovery resource requests.

The foregoing description is merely illustrative of the technical idea of the present invention, and various changes and modifications may be made by those skilled in the art without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are intended to illustrate rather than limit the scope of the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. The scope of protection of the present invention should be construed according to the following claims, and all technical ideas within the scope of equivalents should be construed as falling within the scope of the present invention.

190, 200: Network domain

Claims (14)

  1. Receiving a request for discovery resource processing according to a specific filter condition (filterCriteria) in an M2M communication environment;
    Performing a discovery operation according to the filter condition to generate a URI (Uniform Resource Identifier) list as a result; And
    And storing the URI list according to the filter condition as a discovery resource.
  2. The method according to claim 1,
    Wherein the discovery resource is generated as a dependent resource of a discovery collection resource.
  3. The method according to claim 1,
    Wherein the discovery resource includes an attribute indicating the requested filter condition and an attribute indicating a result of performing the discovery, respectively.
  4. The method of claim 3,
    Wherein the filter condition is stored as an attribute of a requested search string (requestedSearchString).
  5. The method of claim 3,
    And the URI list according to a result of the discovery is stored as a discovery result attribute.
  6. The method of claim 3,
    Wherein the discovery resource further includes at least one of attributes indicating a frequency and a frequency of a discovery request for the filter condition.
  7. The method according to claim 1,
    Wherein the filter condition is a search string (searchString).
  8. When the M2M communication system receives a discovery resource request according to a specific filter condition (filterCriteria), it performs a discovery operation according to the filter condition to generate a URI list as a result, and discovers the URI list according to the filter condition discovery resource of the M2M platform.
  9. 9. The method of claim 8,
    Wherein the discovery resource is created as a dependent resource of a discovery collection resource.
  10. 9. The method of claim 8,
    Wherein the discovery resource includes an attribute indicating the requested filter condition and an attribute indicating a result of performing the discovery, respectively.
  11. 11. The method of claim 10,
    Wherein the filter condition is stored as a requestSearchString attribute.
  12. 11. The method of claim 10,
    And the URI list according to a result of the discovery is stored as a discovery result attribute.
  13. 11. The method of claim 10,
    Wherein the discovery resource further includes at least one of attributes indicating a frequency and a frequency of a discovery request for the filter condition.
  14. 9. The method of claim 8,
    Wherein the filter condition is a search string (searchString).
KR1020130017712A 2013-02-19 2013-02-19 A method for searching information of M2M systems and apparatus therefor KR101986851B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020130017712A KR101986851B1 (en) 2013-02-19 2013-02-19 A method for searching information of M2M systems and apparatus therefor

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020130017712A KR101986851B1 (en) 2013-02-19 2013-02-19 A method for searching information of M2M systems and apparatus therefor

Publications (2)

Publication Number Publication Date
KR20140103786A KR20140103786A (en) 2014-08-27
KR101986851B1 true KR101986851B1 (en) 2019-06-07

Family

ID=51747982

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020130017712A KR101986851B1 (en) 2013-02-19 2013-02-19 A method for searching information of M2M systems and apparatus therefor

Country Status (1)

Country Link
KR (1) KR101986851B1 (en)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012035367A1 (en) 2010-09-14 2012-03-22 Nokia Corporation D2d communication procedures: beaconing; broadcast; conflict resolution
WO2012068465A1 (en) 2010-11-19 2012-05-24 Interdigital Patent Holdings, Inc. Machine-to-machine (m2m) interface procedures for announce and de-announce of resources

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101611649B1 (en) * 2008-01-18 2016-04-26 인터디지탈 패튼 홀딩스, 인크 Method and apparatus for enabling machine to machine communication
MX2012010363A (en) * 2010-03-09 2012-11-30 Interdigital Patent Holdings Method and apparatus for supporting machine-to-machine communications.
KR20120124345A (en) * 2011-05-03 2012-11-13 주식회사 케이티 A Method and Apparatus of managing connection between M2M communication entities based on connection state confirmation event

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012035367A1 (en) 2010-09-14 2012-03-22 Nokia Corporation D2d communication procedures: beaconing; broadcast; conflict resolution
WO2012068465A1 (en) 2010-11-19 2012-05-24 Interdigital Patent Holdings, Inc. Machine-to-machine (m2m) interface procedures for announce and de-announce of resources

Also Published As

Publication number Publication date
KR20140103786A (en) 2014-08-27

Similar Documents

Publication Publication Date Title
JP5404766B2 (en) Method and system for requesting routing
US8671221B2 (en) Method and system for increasing speed of domain name system resolution within a computing device
JP5893034B2 (en) Request routing in network environments
KR101167833B1 (en) Data synchronization protocol
JP5828760B2 (en) Method and system for cache optimization
EP2547040A1 (en) Group communication method and device for use in group communication
EP3043530A1 (en) Method and apparatus for implementing subscription notification
EP2783500B1 (en) Method of processing a request in an information-centred communication network
US8463915B1 (en) Method for reducing DNS resolution delay
KR20170075808A (en) Method and apparatus for the virtualization of resources using a virtualization broker and context information
US8489637B2 (en) User-based DNS server access control
WO2007082486A1 (en) An implementing method of data synchronization and the apparatus thereof
CN102624920B (en) A method of accessing via a proxy server apparatus and
ES2594009T3 (en) Group communication procedure and group server
KR20160009613A (en) Semantics support and management in m2m systems
US9832076B2 (en) Resource change management in machine to machine network
KR101858542B1 (en) Container Name Server and Container Name Interpretation Method
JP2009514074A (en) Method, system, client and server for performing data synchronization
JP2016505942A (en) Method and apparatus for access authorization authentication in a wireless communication system
US20140280859A1 (en) Sharing control system and method for network resources download information
JP4009591B2 (en) Domain naming system (DNS) for accessing databases
CN102227901B (en) Trickle sync protocol
CN104093118A (en) Resource notification method, machine-to-machine nodes and system
EP3175602A2 (en) Server for device location registration in an internet of things (iot)
RU2615057C2 (en) Method and device for access to web-page and router

Legal Events

Date Code Title Description
A201 Request for examination
E701 Decision to grant or registration of patent right