Method and apparatus for edge transfer based on movement of user equipment

Abstract

The present invention relates to a method and apparatus for providing edge transfer in response to the movement of a terminal. More specifically, the invention proposes a method of operation for an M2M device comprising the steps of: recognizing the occurrence of a handover from a network and receiving handover information when a network function virtualization instance of a source edge is transferred to a target edge; and replicating an M2M service instance of the source edge and transferring it to an M2M edge node, wherein the network function virtualization instance and the M2M service instance are transferred independently or non-independently based on the characteristics of the target edge. According to the present invention, continuous M2M service provision to a terminal is possible even if a handover occurs due to the movement of a terminal in an M2M system.

Description

Technology Field

[0001] The present invention relates to a method and apparatus for providing an edge transfer when a handover occurs due to the movement of a terminal in a machine-to-machine (M2M) system. More specifically, the present invention relates to a method and apparatus for reliably transferring an edge instance to a target edge in an M2M system. Background Technology

[0003] Recently, the adoption of M2M (Machine-to-Machine) systems has been increasing rapidly. M2M communication can refer to communication performed between machines without human intervention. M2M can refer to Machine Type Communication (MTC), the Internet of Things (IoT), or Device-to-Device (D2D). However, for the convenience of explanation, the term M2M will be used consistently below, but it is not limited to this. The terminal used for M2M communication may be an M2M terminal (M2M device). An M2M terminal is generally a device with low mobility that transmits small amounts of data. In this case, the M2M terminal can be used in connection with an M2M server that centrally stores and manages communication information between machines.

[0004] In addition, M2M terminals can be applied in various systems, such as object tracking, vehicle integration, and power metering.

[0005] Meanwhile, regarding M2M terminals, the oneM2M standardization organization provides technical specifications for requirements, architecture, API (Application Program Interface) specifications, security solutions, and interoperability for M2M communication, IoT, and IoT technologies. The specifications of the oneM2M standardization organization provide a framework that supports various applications and services, such as smart cities, smart grids, connected cars, home automation, public safety, and health. The problem to be solved

[0007] The objective of the present invention is to provide a method and apparatus for providing stable service to a terminal by transferring an edge instance to a target base station when a handover occurs due to the movement of a terminal in a Machine-to-Machine (M2M) system.

[0008] The objective of the present invention is to provide a method and apparatus for independently or independently transferring a network slice and an M2M service instance when a handover occurs in an M2M system.

[0009] Other objects and advantages of the present invention may be understood from the following description and will become more clearly apparent from the embodiments of the present invention. Furthermore, it will be readily apparent that the objects and advantages of the present invention can be realized by the means and combinations thereof set forth in the claims. means of solving the problem

[0011] According to one embodiment of the present invention, a method for operating an M2M device in a Machine-to-Machine (M2M) system comprises, in the method for operating an M2M device in a Machine-to-Machine (M2M) system, a step of recognizing the occurrence of a handover from a network and receiving handover information when a network function virtualization instance of a source edge is transferred to a target edge, and a step of replicating an M2M service instance of the source edge and transferring it to an M2M edge node, wherein the network function virtualization instance and the M2M service instance are transferred independently or non-independently based on the characteristics of the target edge.

[0012] Meanwhile, if the source edge and target edge are edge nodes that support 3GPP 5G, the target edge and the M2M edge node may be characterized as being the same edge node.

[0013] Meanwhile, the source edge is an edge node that supports 3GPP 5G, and if the target edge cannot host an M2M service instance, it may be characterized by searching for a separate M2M edge node to transfer the M2M service instance.

[0014] Meanwhile, once the above M2M service instance is transferred, the connection between the above M2M service instance and the above network function virtualization instance can be updated.

[0015] Meanwhile, the above M2M edge node may be characterized as being a Road Side Unit or a Smart Building Access Point.

[0016] Meanwhile, the above search may be characterized by being performed based on at least one of DNS, Registry, and mDNS.

[0017] Meanwhile, the handover information may include at least one of the following: information about the source edge and the target edge, the location of the terminal, information about the path the terminal has traveled and the expected path, and the instance hosting capability of the target edge.

[0018] Meanwhile, information regarding the transfer and updated connection of the above edge instance is, <modifiedresource>It can be recorded in resources.

[0019] Meanwhile, the above M2M service instance may include an offloaded instance.

[0020] According to one embodiment of the present invention, in an M2M system, an M2M device comprises a transceiver for transmitting and receiving data and a processor for controlling the transceiver. The processor receives information regarding the handover when a terminal handover occurs, and when a network function virtualization instance at the source edge is transferred to the target edge, transfers an M2M service instance to the M2M edge node. The network function virtualization instance and the M2M service instance may be transferred independently or non-independently based on the characteristics of the target edge.

[0021] Meanwhile, if the source edge and target edge are edge nodes that support 3GPP 5G, the target edge and the M2M edge node may be characterized as being the same edge node.

[0022] Meanwhile, the processor may be characterized by the fact that, when the source edge is an edge node supporting 3GPP 5G and the target edge cannot host the M2M service instance, it searches for a separate M2M edge node to transfer the M2M service instance.

[0023] Meanwhile, when the above M2M service instance is transferred, the connection between the above M2M service instance and the above network function virtualization instance may be updated.

[0024] Meanwhile, the above M2M edge node may be characterized as being a Road Side Unit or a Smart Building Access Point.

[0025] Meanwhile, the above search may be characterized by being performed based on at least one of DNS, Registry, and mDNS.

[0026] Meanwhile, the handover information may include at least one of the following: information about the source edge and the target edge, the location of the terminal, information about the path the terminal has traveled and the expected path, and the instance hosting capability of the target edge.

[0027] Meanwhile, information regarding the transfer and updated connection of the above edge instance is, <modifiedresource>It can be recorded in the attributes.

[0028] Meanwhile, the above M2M service instance may include an offloaded instance.

[0029] According to one embodiment of the present invention, in an M2M system, an M2M terminal (M2M device) includes a transceiver for transmitting and receiving data and a processor for controlling the transceiver. The processor receives a handover decision and connects to a target edge that accommodates a transferred edge instance. The edge instance includes an M2M service instance and a network function virtualization instance. The M2M service instance and the network function virtualization instance may be transferred independently or non-independently based on the characteristics of the target edge. Effects of the invention

[0031] According to the present disclosure, edge instances can be reliably transferred when a handover occurs due to the movement of a terminal in a Machine-to-Machine (M2M) system.

[0032] According to the present disclosure, continuous M2M service can be provided to a terminal even if a handover occurs due to the movement of the terminal in an M2M system.

[0033] The effects obtainable from the present disclosure are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art to which the present disclosure pertains from the description below. Brief explanation of the drawing

[0035] FIG. 1 is a diagram showing the hierarchical structure of a Machine-to-Machine (M2M) system according to the present disclosure. FIG. 2 is a diagram showing a reference point in an M2M system according to the present disclosure. FIG. 3 is a diagram showing each node in an M2M system according to the present disclosure. FIG. 4 is a diagram showing common service functions in an M2M system according to the present disclosure. FIG. 5 is a diagram illustrating a method in which a sender and a receiver exchange messages in an M2M system according to the present disclosure. FIG. 6 is a diagram showing a Mobile Edge Computing (MEC) framework according to the present disclosure. FIGS. 7 and 8 are diagrams illustrating an environment in which edge transfer is performed following a terminal handover in an M2M system according to the present disclosure. FIG. 9 is a diagram showing an edge transfer according to a loosely coupled edge mode in an M2M system according to the present disclosure. FIGS. 10 to 12 are drawings illustrating the edge transfer process according to the weakly coupled edge mode in an M2M system according to the present disclosure in steps. FIG. 13 is a diagram showing different edge transfers according to the weakly coupled edge mode in an M2M system according to the present disclosure. FIG. 14 is a diagram showing different edge transfer processes according to the weakly coupled edge mode of the M2M system according to the present disclosure in steps. FIG. 15 is a diagram showing the edge transfer process according to the tightly coupled edge mode of the M2M system according to the present disclosure in steps. FIG. 16 is a drawing showing an M2M device of an M2M system according to the present disclosure. Specific details for implementing the invention

[0036] Hereinafter, embodiments of the present disclosure are described in detail with reference to the attached drawings so that those skilled in the art can easily implement them. However, the present disclosure may be embodied in various different forms and is not limited to the embodiments described herein.

[0037] In the present disclosure, terms such as first, second, etc. are used solely for the purpose of distinguishing one component from another component and do not limit the order or importance of the components unless specifically stated otherwise. Accordingly, within the scope of the present disclosure, a first component in one embodiment may be referred to as a second component in another embodiment, and likewise, a second component in one embodiment may be referred to as a first component in another embodiment.

[0038] In the present disclosure, when a component is described as being "connected," "combined," or "joined" with another component, this may include not only a direct connection but also an indirect connection in which another component exists in between. Furthermore, when a component is described as "comprising" or "having" another component, this means that, unless specifically stated otherwise, it does not exclude the other component but may include an additional component.

[0039] In this disclosure, distinct components are intended to clearly describe their respective features and do not imply that the components are separate. That is, multiple components may be integrated to form a single hardware or software unit, or a single component may be distributed to form multiple hardware or software units. Accordingly, such integrated or distributed embodiments are included within the scope of this disclosure, even if not otherwise mentioned.

[0040] In the present disclosure, the components described in various embodiments are not necessarily essential components, and some may be optional components. Accordingly, embodiments consisting of a subset of the components described in one embodiment are also included within the scope of the present disclosure. Furthermore, embodiments including additional components in addition to the components described in various embodiments are also included within the scope of the present disclosure.

[0041] In describing the embodiments of the present disclosure, if it is determined that a detailed description of known configurations or functions could obscure the essence of the present disclosure, such detailed description is omitted. Additionally, parts of the drawings unrelated to the description of the present disclosure have been omitted, and similar parts are denoted by similar reference numerals.

[0042] In addition, this specification describes a network based on M2M (Machine-to-Machine) communication, and operations performed in an M2M communication network may be carried out in the process of controlling the network and transmitting data by a system governing the communication network.

[0043] Furthermore, in this specification, an M2M terminal may be a terminal that performs M2M communication, but may also be a terminal that operates in a wireless communication system with backward compatibility in mind. That is, an M2M terminal may refer to a terminal that can operate based on an M2M communication network, but is not limited to an M2M communication network. An M2M terminal may also be capable of operating based on other wireless communication networks and is not limited to the embodiments described above.

[0044] In addition, M2M terminals can be fixed or mobile. Furthermore, an M2M server refers to a server for M2M communication and can be a fixed station or a mobile station.

[0045] Additionally, in this specification, an entity may refer to hardware such as an M2M device, an M2M gateway, or an M2M server. Furthermore, as an example, an entity may be used to refer to a software configuration in the hierarchical structure of an M2M system, and is not limited to the embodiments described above.

[0046] In addition, as an example, the present invention is described with reference to an M2M system, but the present invention is not limited to an M2M system.

[0047] Additionally, the M2M server may be a server that communicates with an M2M terminal or another M2M server. Furthermore, the M2M gateway may serve as a connection point connecting the M2M terminal and the M2M server. For example, if the networks of the M2M terminal and the M2M server are different, they may be connected to each other through the M2M gateway. In this case, for example, both the M2M gateway and the M2M server may be M2M terminals, but are not limited to the embodiments described above.

[0048] Additionally, in the present disclosure, M2M service platform instances and M2M service instances may be used interchangeably.

[0049] Additionally, in the present disclosure, edge nodes may be used interchangeably with edges.

[0050] Additionally, in the present disclosure, the term M2M terminal may be used interchangeably with M2M device and M2M terminal.

[0051] In addition, in the present disclosure, a network function virtualization instance is a concept that includes all instances that can be included in a network slice instance and can be deployed on an edge node, and may include network slice subnet instances, NFV (Network Function Virtualization) instances, etc.

[0053] oneM2M is a de facto standardization organization established to develop a common IoT service platform that integrates and shares application service infrastructure (platform) environments, moving away from fragmented service platform development structures that operate in a dependent and closed manner by industry, such as energy, transportation, defense, and public services. oneM2M aims to provide requirements, architecture, API (Application Program Interface) specifications, security solutions, and interoperability for IoT and IoT technologies. For example, oneM2M specifications provide a framework that supports various applications and services, such as smart cities, smart grids, connected cars, home automation, public safety, and health. To this end, oneM2M has developed a set of standards that defines a single horizontal platform for the exchange and sharing of data among all applications. The applications considered by oneM2M may include those spanning different industrial sectors. By providing a framework for interoperability with different technologies—much like an operating system—oneM2M is creating a distributed software layer that promotes unification. The distributed software layer is implemented in a common service layer located between the communication hardware / software that provides data transmission and M2M applications. For example, the common service layer may occupy part of a layered structure such as Fig. 1.

[0055] FIG. 1 is a diagram showing the layered structure of a Machine-to-Machine (M2M) system according to the present disclosure.

[0056] Referring to FIG. 1, the layered structure of the M2M system may consist of an application layer (110), a common service layer (120), and a network service layer (120). In this case, the application layer (110) may be a layer that operates based on a specific application. For example, the application may be a fleet tracking application, a remote blood sugar monitoring application, a power metering application, or a controlling application. That is, the application layer may be a layer for a specific application. In this case, the entity that operates based on the application layer may be an Application Entity (AE).

[0057] The common service layer (120) may be a layer for a common service function (CSF). For example, the common service layer (120) may be a layer for providing common services such as data management, device management, M2M service subscription management, location services, etc. For example, an entity operating based on the common service layer (120) may be a common service entity (CSE).

[0058] The common service layer (120) may provide a set of services that are grouped into CSFs by function. A number of instantiated CSFs form CSEs. CSEs may interface with applications (e.g., application entities or AEs in oneM2M nomenclature), other CSEs, and underlying networks (e.g., network service entities or NSEs in oneM2M nomenclature).

[0059] The network service layer (120) can provide services such as device management, location service, and device triggering to the common service layer (120). At this time, the entity operating based on the network layer (120) may be a network service entity (NSE).

[0061] FIG. 2 is a diagram showing a reference point in an M2M system according to the present disclosure.

[0062] Referring to FIG. 2, the M2M system structure can be distinguished into a Field Domain and an Infrastructure Domain. In this case, each entity in each domain can communicate through a reference point (e.g., Mca, or Mcc). For example, a reference point can represent the communication flow between each entity. In this case, referring to FIG. 2, an Mca reference point, which is a reference point between AE (210 or 240) and CSE (220 or 250), an Mcc reference point, which is a reference point between different CSEs, and a Mcn reference point, which is a reference point between CSE (220 or 250) and NSE (230 or 260), can be established.

[0064] FIG. 3 is a diagram showing each node in an M2M system according to the present disclosure.

[0065] Referring to FIG. 3, the infrastructure domain of a specific M2M service provider may provide a specific infrastructure node (310, Infrastructure Node, IN). In this case, the CSE of the IN may communicate with the AE of another infrastructure node based on the Mca reference point. In this case, one IN may be configured for each M2M service provider. That is, the IN may be a node that communicates with an M2M terminal of another infrastructure based on the infrastructure structure. Additionally, as an example, the concept of a node may be a logical entity or a software configuration.

[0066] Next, the Application Dedicated Node (320, ADN) may be a node that includes at least one AE and does not include a CSE. In this case, the ADN may be configured in a field domain. That is, the ADN may be a node dedicated to the AE. For example, the ADN may be a node configured in hardware on an M2M terminal. Additionally, the Application Service Node (330, ASN) may be a node that includes one CSE and at least one AE. The ASN may be configured in a field domain. That is, it may be a node that includes an AE and a CSE. In this case, the ASN may be a node connected to an IN. For example, the ASN may be a node configured in hardware on an M2M terminal.

[0067] Additionally, the middle node (340, Middle Node, MN) may be a node that includes a CSE and zero or more AEs. In this case, the MN may be configured in a field domain. The MN may be connected to other MNs or INs based on a reference point. Also, as an example, the MN may be configured in hardware on an M2M gateway.

[0068] In addition, as an example, a non-M2M device node (350, Non-M2M device node, NoDN) is a node that does not contain M2M entities and may be a node that performs management or collaboration with an M2M system.

[0070] FIG. 4 is a diagram showing common service functions in an M2M system according to the present disclosure.

[0071] Referring to FIG. 4, common service functions may be provided. For example, a common service entity may provide at least one of the following CSFs: Application and Service Layer Management (402), Communication Management and Delivery Handling (404), Data Management and Repository (406), Device Management (408), Discovery (410), Group Management (412), Location (414), Network Service Exposure / Service Execution and Triggering (416), Registration (418), Security (420), Service Charging and Accounting (422), Service Session Management, and Subscription / Notification (424). At this time, M2M terminals may operate based on the common service functions. In addition, the common service function may have other embodiments and is not limited to the embodiments described above.

[0072] Application and Service Layer Management (402) CSF provides management of AEs and CSEs. Application and Service Layer Management (402) CSF includes the ability to configure, troubleshoot, and upgrade the functions of CSEs, as well as upgrade AEs.

[0073] The communication management and forwarding processing (404) CSF provides communications with other CSEs, AEs, and NSEs. The communication management and forwarding processing (404) CSF determines when and to which communication connection to forward communications and decides to buffer communication requests so that they can be forwarded later if necessary and permissible.

[0074] Data Management and Storage (406) CSF provides data storage and mediation functions (e.g., data collection for aggregation, data reformatting, and data storage for analysis and semantic processing).

[0075] Device management (408) CSF provides management of device capabilities on M2M gateways and M2M devices.

[0076] Discovery (410) CSF provides a function to search for information about applications and services based on filter criteria.

[0077] The group management (412) CSF provides processing of group-related requests. The group management (412) CSF enables the M2M system to support bulk operations on multiple devices, applications, etc.

[0078] Location (414) CSF provides a function that enables AEs to obtain geographical location information.

[0079] Network service exposure / service execution and triggering (416) CSF manages communications with underlying networks to access network service functions.

[0080] Registration (418) CSF provides a function for AEs (or other remote CSEs) to register with the CSE. Registration (418) CSF allows AEs (or remote CSEs) to use the services of the CSE.

[0081] Security (420) CSF provides security functions for service layers such as access control including identification, authentication, and authorization.

[0082] Service billing and calculation (422) CSF provides billing functions for the service layer.

[0083] Subscription / Notification (424) CSF allows subscription to events and provides a function to be notified when the event occurs.

[0085] FIG. 5 is a diagram illustrating a method in which a sender and a receiver exchange messages in an M2M system according to the present disclosure.

[0086] Referring to FIG. 5, the sender (Originator, 510) can transmit a request message to the receiver (Receiver, 520). At this time, the sender (510) and the receiver (520) may be the M2M terminals described above. However, they are not limited to M2M terminals, and the sender (510) and the receiver (520) may be other terminals and are not limited to the embodiments described above. Additionally, as an example, the sender (510) and the receiver (520) may be the nodes, entities, servers, or gateways described above. That is, the sender (510) and the receiver (520) may be hardware or software configurations and are not limited to the embodiments described above.

[0087] In this case, for example, the request message transmitted by the sender (510) may include at least one parameter. In this case, for example, the parameter may be a mandatory parameter or an optional parameter. For example, parameters related to the sending end, parameters related to the receiving end, identification parameters, and operation parameters may be mandatory parameters. Additionally, other information may be optional parameters. In this case, the parameters related to the sending end may be parameters for the sender (510). Additionally, the parameters related to the receiving end may be parameters for the receiver (520). Additionally, the identification parameters may be parameters required for mutual identification.

[0088] Additionally, the action parameter may be a parameter for distinguishing actions. For example, the action parameter may be set to at least one of Create, Retrieve, Update, Delete, and Notify. In other words, it may be a parameter for distinguishing actions.

[0089] At this time, when the receiver (520) receives a request message from the sender (510), it can process the request message. For example, the receiver (520) can perform an action included in the request message, and to do so, it can determine whether the parameters are valid and whether there is permission. At this time, if the parameters are valid and there is permission, the receiver (520) can check whether the resource to be requested exists and perform processing based on this.

[0090] For example, when an event occurs, the sender (510) may send a request message containing parameters for a notification to the receiver (520). The receiver (520) may check the parameters for the notification included in the request message, perform an action based thereon, and send a response message back to the sender (510).

[0091] A message exchange procedure using request and response messages as shown in FIG. 5 can be performed between an AE and a CSE based on an Mca reference point or between CSEs based on an Mcc reference point. That is, the sender (510) may be an AE or a CSE, and the receiver (520) may be an AE or a CSE. Depending on the operation within the request message, a message exchange procedure as shown in FIG. 5 may be initiated by an AE or a CSE.

[0093] Requests from a requester to a receiver through reference points Mca and Mcc may include at least one mandatory parameter and at least one optional parameter. That is, each defined parameter may be mandatory or optional depending on the requested operation. For example, a response message may include at least one of the parameters listed in below.

[0094] Response message parameter / success or not Response Status Code - successful, unsuccessful, ack Request Identifier - uniquely identifies a Request message Content - to be transferred To - the identifier of the Originator or the Transit CSE that sent the corresponding non-blocking request From - the identifier of the Receiver Originating Timestamp - when the message was built Result Expiration Timestamp - when the message expires Event Category - what event category shall be used for the response message Content Status Content Offset Token Request Information Assigned Token Identifiers Authorization Signature Request Information Release Version Indicator - the oneM2M release version that this response message conforms to

[0095] Filter criteria conditions that can be used in request messages or response messages can be defined as shown in and below.

[0096] Condition tag Multip-licity Description Matching Conditions createdBefore 0..1 The creationTime attribute of the matched resource is chronologically before the specified value. createdAfter 0..1 The creationTime attribute of the matched resource is chronologically after the specified value. modifiedSince 0..1 The lastModifiedTime attribute of the matched resource is chronologically after the specified value. unmodifiedSince 0..1 The lastModifiedTime attribute of the matched resource is chronologically before the specified value. stateTagSmaller 0..1 The stateTag attribute of the matched resource is smaller than the specified value. stateTagBigger 0..1 The stateTag attribute of the matched resource is bigger than the specified value. expireBefore 0..1 The expirationTime attribute of the matched resource is chronologically before the specified value. expireAfter 0..1 The expirationTime attribute of the matched resource is chronologically after the specified value. labels 0..1 The labels attribute of the matched resource matches the specified value. labelsQuery 0..1 The value is an expression for the filtering of labels attribute of resource when it is of key-value pair format. The expression is about the relationship between label-key and label-value which may include equal to or not equal to, within or not within a specified set etc. For example, label-key equals to label value, or label-key within {label-value1, label-value2}. Details are defined in [3] childLabels 0..1 A child of the matched resource has labels attributes matching the specified value. The evaluation is the same as for the labels attribute above. Details are defined in [3]. parentLabels 0..1 The parent of the matched resource has labels attributes matching the specified value. The evaluation is the same as for the labels attribute above. Details are defined in [3]. resourceType 0..n The resourceType attribute of the matched resource is the same as the specified value. It also allows differentiating between normal and announced resources. childResourceType 0..n A child of the matched resource has the resourceType attribute the same as the specified value. parentResourceType 0..1 The parent of the matched resource has the resourceType attribute the same as the specified value. sizeAbove 0..1 The contentSize attribute of the <contentinstance> matched resource is equal to or greater than the specified value. < / contentinstance> sizeBelow 0..1 The contentSize attribute of the <contentinstance> matched resource is smaller than the specified value. < / contentinstance> contentType 0..n The contentInfo attribute of the <contentinstance> matched resource matches the specified value. < / contentinstance> attribute 0..n This is an attribute of resource types (clause 9.6). Therefore, a real tag name is variable and depends on its usage and the value of the attribute can have wild card *. E.g. creator of container resource type can be used as a filter criteria tag as "creator=Sam", "creator=Sam*", "creator=*Sam". childAttribute 0..n A child of the matched resource meets the condition provided. The evaluation of this condition is similar to the attribute matching condition above. parentAttribute 0..n The parent of the matched resource meets the condition provided. The evaluation of this condition is similar to the attribute matching condition above. semanticsFilter 0..n Both semantic resource discovery and semantic query use semanticsFilter to specify a query statement that shall be specified in the SPARQL query language [5]. When a CSE receives a RETRIEVE request including a semanticsFilter, and the Semantic Query Indicator parameter is also present in the request, the request shall be processed as a semantic query; otherwise, the request shall be processed as a semantic resource discovery. In the case of semantic resource discovery targeting a specific resource, if the semantic description contained in the <semanticdescriptor> of a child resource matches the semanticFilter, the URI of this child resource will be included in the semantic resource discovery result. In the case of semantic query, given a received semantic query request and its query scope, the SPARQL query statement shall be executed over aggregated semantic information collected from the semantic resource(s) in the query scope and the produced output will be the result of this semantic query. Examples for matching semantic filters in SPARQL to semantic descriptions can be found in [i.28]. < / semanticdescriptor> filterOperation 0..1 Indicates the logical operation (AND / OR) to be used for different condition tags. The default value is logical AND. contentFilterSyntax 0..1 Indicates the Identifier for syntax to be applied for content-based discovery. contentFilterQuery 0..1 The query string shall be specified when contentFilterSyntax parameter is present.

[0097] Condition tag Multip-licity Description Filter Handling Conditions filterUsage 0..1 Indicates how the filter criteria is used. If provided, possible values are 'discovery' and 'IPEOnDemandDiscovery'.If this parameter is not provided, the Retrieve operation is a generic retrieve operation and the content of the child resources fitting the filter criteria is returned.If filterUsage is 'discovery', the Retrieve operation is for resource discovery (clause 10.2.6), i.e. only the addresses of the child resources are returned.If filterUsage is 'IPEOnDemandDiscovery', the other filter conditions are sent to the IPE as well as the discovery Originator ID. When the IPE successfully generates new resources matching with the conditions, then the resource address(es) shall be returned. This value shall only be valid for the Retrieve request targeting an <ae> resource that represents the IPE. < / ae> limit 0..1 The maximum number of resources to be included in the filtering result. This may be modified by the Hosting CSE. When it is modified, then the new value shall be smaller than the suggested value by the Originator. level 0..1 The maximum level of resource tree that the Hosting CSE shall perform the operation starting from the target resource (i.e. To parameter). This shall only be applied for Retrieve operation. The level of the target resource itself is zero and the level of the direct children of the target is one. offset 0..1 The number of direct child and descendant resources that a Hosting CSE shall skip over and not include within a Retrieve response when processing a Retrieve request to a targeted resource. applyRelativePath 0..1 This attribute contains a resource tree relative path (e.g. .. / tempContainer / LATEST). This condition applies after all the matching conditions have been used (i.e. a matching result has been obtained). The attribute determines the set of resource(s) in the final filtering result. The filtering result is computed by appending the relative path to the path(s) in the matching result. All resources whose Resource-IDs match that combined path(s) shall be returned in the filtering result. If the relative path does not represent a valid resource, the outcome is the same as if no match was found, i.e. there is no corresponding entry in the filtering result.

[0098] A response to a request for accessing resources through reference points Mca and Mcc may include at least one mandatory parameter and at least one optional parameter. That is, each defined parameter may be mandatory or optional depending on the requested operation or mandatory response code. For example, a request message may include at least one of the parameters listed in below.

[0099] Request message parameter Mandatory Operation - operation to be executed / CREAT, Retrieve, Update, Delete, Notify To - the address of the target resource on the target CSE From - the identifier of the message Originator Request Identifier - uniquely identifies a Request message Operation dependent Content - to be transferred Resource Type - of resource to be created Optional Originating Timestamp - when the message was built Request Expiration Timestamp - when the request message expires Result Expiration Timestamp - when the result message expires Operational Execution Time - the time when the specified operation is to be executed by the target CSE Response Type - type of response that shall be sent to the Originator Result Persistence - the duration for which the reference containing the responses is to persist Result Content - the expected components of the result Event Category - indicates how and when the system should deliver the message Delivery Aggregation - aggregation of requests to the same target CSE is to be used Group Request Identifier - Identifier added to the group request that is to be fanned out to each member of the group Group Request Target Members-indicates subset of members of a group Filter Criteria - conditions for filtered retrieve operation Desired Identifier Result Type - format of resource identifiers returned Token Request Indicator - indicating that the Originator may attempt Token Request procedure (for Dynamic Authorization) if initiated by the Receiver Tokens - for use in dynamic authorization Token IDs - for use in dynamic authorization Role IDs - for use in role based access control Local Token IDs - for use in dynamic authorization Authorization Signature Indicator - for use in Authorization Relationship Mapping Authorization Signature - for use in Authorization Relationship Mapping Authorization Relationship Indicator - for use in Authorization Relationship Mapping Semantic Query Indicator - for use in semantic queries Release Version Indicator - the oneM2M release version that this request message conforms to. Vendor Information

[0100] A normal resource includes a complete set of representations of data that constitute the base of the information to be managed. Unless virtual or announced, resource types in this document may be understood as normal resources.

[0101] Virtual resources are used to trigger processing and / or retrieval results. However, virtual resources do not have a permanent representation within CSE.

[0102] An announced resource contains a set of attributes of the original resource. When the original resource changes, the announced resource is automatically updated by the original resource's hosting CSE. The announced resource contains a link to the original resource.

[0103] Resource announcement enables resource discovery. A declared resource in a remote CSE can be used to create child resources in the remote CSE that are not present as children of the original resource or are not declared children.

[0104] To support the declaration of resources, additional columns within the resource template can specify the attributes to be declared for inclusion within the related declared resource type. Each declared <resourcetype>Regarding, original <resourcetype>The addition of the suffix 'Annc' to can be used to indicate the related declared resource type. For example, resource <containerannc>Is <container>You can specify the declared resource type for the resource, and <groupannc>Is <group>It can indicate the declared resource type for.

[0105] Resources are specified in relation to the CSE. Resources are representations within the CSE of components and elements within the oneM2M system. Other CSEs, AEs, application data representing sensors, commands, etc., are known to the CSE as a means of resource representation.

[0106] Resources are uniquely addressable entities in the onoM2M architecture. Resources are passed and can be manipulated using CRUD (Create, Retrieve, Update, Delete) operations.

[0107] A child resource is a sub-resource of another resource, which is a parent resource. A parent resource contains a reference to at least one child resource.

[0108] An attribute stores information related to a resource. A set of attributes is not enumerated within the graphical representation of a resource unless it is common to all resources.

[0109] Attributes are classified into universal attributes, common attributes, and resource-specific attributes. Universal attributes are attributes that appear in all resources, while common attributes appear in multiple resources and have the same meaning regardless of where they appear.

[0110] Examples of virtual or undeclared general and universal attributes for all resource types are shown in below.

[0111] Attribute Name Description resourceType Resource Type. This Read Only (assigned at creation time. and then cannot be changed) attribute identifies the type of the resource as specified in clause 9.6. Each resource shall have a resourceType attribute. resourceID This attribute is an identifier for the resource that is used for 'non-hierarchical addressing method', i.e. this attribute shall contain the 'Unstructured-CSE-relative-Resource-ID' format of a resource ID as defined in table 7.2-1. This attribute shall be provided by the Hosting CSE when it accepts a resource creation procedure. The Hosting CSE shall assign a resourceID which is unique in that CSE. resourceName This attribute is the name for the resource that is used for 'hierarchical addressing method' to represent the parent-child relationships of resources. See clause 7.2 for more details.This attribute may be provided by the resource creator. The Hosting CSE shall use a provided resourceName as long as it does not already exist among child resources of the targeted parent resource. If the resourceName already exists, the Hosting CSE shall reject the request and return an error to the Originator. The Hosting CSE shall assign a resourceName if one is not provided by the resource creator. parentID This attribute is the resourceID of the parent of this resource. The value of this attribute shall be NULL for the <csebase> resource type. < / csebase> creationTime Time / date of creation of the resource.This attribute is mandatory for all resources and the value is assigned by the system at the time when the resource is locally created. Such an attribute cannot be changed. lastModifiedTime Last modification time / date of the resource.The lastModifiedTime value is set by the Hosting CSE when the resource is created, and the lastModifiedTime value is updated when the resource is updated.

[0112] Examples of attributes commonly used in multiple resource types that are virtual or undeclared, general, but not all, are shown in below.

[0113] Attribute Name Description accessControlPolicyIDs The attribute contains a list of identifiers for <accesscontrolpolicy>resources. The privileges defined in the <accesscontrolpolicy>resources that are referenced determine who is allowed to access the resource containing this attribute for a specific purpose (e.g. Retrieve, Update, Delete, etc.).For an Update or Delete operation to a resource, the update or delete of the accessControlPolicyIDs attribute, if applicable, shall be performed prior to the update or delete of any other attributes of the resource. To update this attribute, a Hosting CSE shall check whether an Originator has Update privilege in any selfPrivileges, regardless of privileges, of the <accesscontrolpolicy>resources which this attribute originally references.After successful update of the accessControlPolicyIDs attribute, resource access checking for other attributes to be updated shall use the new privileges defined in the <accesscontrolpolicy>resource(s) that are referenced by the newly updated accessControlPolicyIDs attribute. Similarly, to delete this attribute, a Hosting CSE shall check whether an Originator has Updateprivilege in any selfPrivileges, regardless of privileges, of the <accesscontrolpolicy>resources which this attribute originally references.After successful deletion of the accessControlPolicyIDs attribute, resource access checking for other attributes to be deleted shall use the default access privileges as described in the following paragraphs. If a resource type does not have an accessControlPolicyIDs attribute definition, then the accessControlPolicyIDs for that resource is governed in a different way, for example, the accessControlPolicy associated with the parent may apply to a child resource that does not have an accessControlPolicyIDs attribute definition, or the privileges for access are fixed by the system. Refer to the corresponding resource type definitions and procedures to see how access control is handled in such cases.If a resource type does have an accessControlPolicyIDs attribute definition, but the (optional) accessControlPolicyIDs attribute value is not set in a resource instance, then the Hosting CSE shall apply the concept of the default access policy. The default policy shall provide unrestricted access only to the Originator of the successful resource creation request. All other entities shall be denied to access the resource. For that purpose, the Hosting CSE shall keep that Originator information of the resource. Note that how to keep that information is implementation specific. The default access policy is not applied to a resource which has a value assigned to the accessControlPolicyIDs attribute. All resources are accessible if and only if the privileges (i.e. configured as privileges or selfPrivileges attribute of . <accesscontrolpolicy> resource) allow it, therefore all resources shall have an associated accessControlPolicyIDs attribute, either explicitly (setting the attribute in the resource itself) or implicitly (either by using the parent privileges or the system default policies). Which means that the system shall provide default access privileges in case that the Originator does not provide a specific accessControlPolicyIDs during the creation of the resource. < / accesscontrolpolicy> < / accesscontrolpolicy> < / accesscontrolpolicy> < / accesscontrolpolicy> < / accesscontrolpolicy> < / accesscontrolpolicy> expirationTime Time / date after which the resource will be deleted by the Hosting CSE. This attribute can be provided by the Originator, and in such a case it will be regarded as a hint to the Hosting CSE on the lifetime of the resource. The Hosting CSE shall configure the expirationTime value. If the Hosting CSE configures the new expirationTime attribute value rather than the Originator suggested value, the new value can be sent back to the Originator depending on the Result Content value.The lifetime of the resource can be extended by providing a new value for this attribute in an UPDATE operation. Or by deleting the attribute value, e.g. by updating the attribute with NULL when doing a full UPDATE, in which case the Hosting CSE can decide on a new value.If the Originator does not provide a value in the CREATE operation the system shall assign an appropriate value depending on its local policies and / or M2M service subscription agreements.A resource is known as 'obsolete' when the resource contains the attribute "expirationTime" and the lifetime of this resource has reached the value of this attribute. If the ‘obsolete’ resource had a reference to an Application Entity Resource ID, the Hosting CSE shall send a NOTIFY request to the IN-CSE, requesting to delete the entry from the . <aecontactlist> resource. < / aecontactlist> stateTag An incremental counter of modification on the resource. When a resource is created, this counter is set to 0, and it will be incremented on every modification of the resource (see notes 1 and 2). announceTo This attribute may be included in a CREATE or UPDATE Request in which case it contains a list of addresses / CSE-IDs where the resource is to be announced. For the case that CSE-IDs are provided, the announced-to CSE shall decide the location of the announced resources based on the rules described in clause 9.6.26. For the original resource, this attribute shall only be present if it has been successfully announced to other CSEs. This attribute maintains the list of the resource addresses to the successfully announced resources. Updates on this attribute will trigger new resource announcement or de-announcement. If announceTo attribute includes resource address(s), the present document does not provide any means for validating these address(s) for announcement purposes. It is the responsibility of the Hosting-CSE referenced by the resource address(s) to validate the access privileges of the originator of the Request that triggers the announcement. announcedAttribute This attributes shall only be present at the original resource if some Optional Announced (OA) type attributes have been announced to other CSEs. This attribute maintains the list of the announced Optional Attributes (OA type attributes) in the original resource. Updates to this attribute will trigger new attribute announcement if a new attribute is added or de-announcement if the existing attribute is removed. labels Tokens used to add meta-information to resources.This attribute is optional.The value of the labels attribute is a list of individual labels, each of them being:- Either a standalone label-key, used as a simple "tag", that can be used for example for discovery purposes when looking for particular resources that one can "tag" using that label-key- Or a composite element made of a label-key and a label-value, separated by a special character defined in [3]. The list of allowed characters in a label (and in label-keys and label-values) and separator characters is defined in [3], clause 6.3.3. e2eSecInfo Present in a resource representing an AE or CSE. Indicates the end-to-end security capabilities supported by the AE or CSE. May indicate supported end-to-end security frameworks. May also contains a certificate or credential identifier used by the AE or CSE. May include random values for use in end-to-end security protocols. The details of this attributes are described in oneM2M TS-0003 [2].This attribute is optional and if not present it means that the represented entity does not support oneM2M end-to-end security procedures. DynamicAuthorizationConsultationIDs This attribute contains a list of identifiers of <dynamicauthorizationconsultation>resources. The information defined in a <dynamicauthorizationconsultation>resource is used by a CSE for initiating consultation-based dynamic authorization requests.Consultation-based dynamic authorization is only performed for a targeted resource if and only if it is linked to an enabled <dynamicauthorizationconsultation>resource.If the attribute is not set or has a value that does not correspond to a valid <dynamicauthorizationconsultation>resource(s), or it refers to an <dynamicauthorizationconsultation>resource(s) that is not reachable, then the dynamicAuthorizationConsultationIDs associated with the parent may apply to the child resource if present, or a system default <dynamicauthorizationconsultation> may apply if present.< / dynamicauthorizationconsultation> < / dynamicauthorizationconsultation> < / dynamicauthorizationconsultation> < / dynamicauthorizationconsultation> < / dynamicauthorizationconsultation> < / dynamicauthorizationconsultation>

[0114] The oneM2M system supports an expiration timer to delete resources from the hosting CSE after a specific amount of time or date. IoT services with temporary access characteristics can use the expiration timer. By means of the expiration timer, resources can be deleted after a given time interval.

[0115] According to the present disclosure, the AE resources of the M2M system additionally <modifiedresource>It may include attributes or sub-resources, which will be explained in more detail in Fig. 8 below.

[0117] FIG. 6 is a diagram of a Mobile Edge Computing (MEC) framework according to the present disclosure. The MEC framework includes basic entities for hosting mobile edge applications and can be grouped into a mobile edge system level (601), a mobile edge host level (611), and a network level (621).

[0118] As an example, at the Mobile Edge System Level (601), a terminal, a third party (3 rd The party, etc. may be included, and a Mobile Edge System Level Management may be included. The Mobile Edge System Level Management may include a Mobile Edge Orchestrator (602), an Operations Support System (603), etc.

[0119] Meanwhile, the Mobile Edge Orchestrator (602) is a core element that can be implemented at the mobile edge system level and may include an overview of the mobile edge system and application packages on-board. It may also validate the rules and requirements of the application. In addition, it may trigger application instantiation and termination, and select an appropriate mobile edge host.

[0120] Additionally, the operating system support system (603) communicates with the mobile edge orchestrator (602) through a specific reference point and can receive requests for the instantiation or termination (completion) of an application from the application of the terminal (UE). Furthermore, it can receive various requests through the CFS portal (Customer Facing Service Portal).

[0121] In one embodiment, the Mobile Edge Host Level (611) may include a Mobile Edge Host and a Mobile Edge Host Level Management, and the Mobile Edge Host may include a Mobile Edge Platform (612), a Mobile Edge Application (613), and a Virtualization Infrastructure (614). Additionally, the Mobile Edge Host Level Management may include a Mobile Edge Platform Manager (615), a Virtualization Infrastructure Manager (616), etc.

[0122] Meanwhile, the Mobile Edge Platform (612) may be a set of essential functions required to run a Mobile Edge Application (613), and the Mobile Edge Application (613) may discover, notify, use, and provide Mobile Edge services using a specific reference point. Additionally, the Mobile Edge Platform (612) may communicate with other Mobile Edge Hosts through the reference point.

[0123] A mobile edge application (613) can be executed by a virtual machine (VM) on a mobile edge host. The virtual machine can interact with the mobile edge platform (612) through a specific reference point and can use and provide mobile edge services.

[0124] Meanwhile, the virtualization infrastructure (614) may include a data plane that executes traffic rules received from the mobile edge platform (612). Additionally, it can regulate and route traffic between various networks, including external and internal networks and 3GPP networks, DNS servers / proxys, various services, and applications. Furthermore, it can provide network resources, storage, and computing resources for the mobile edge application (613).

[0125] The Mobile Edge Platform Manager (615) can manage the life cycle of an application and provide element management functions to the Mobile Edge Platform (612). In addition, it can manage the rules and requirements of the application and receive performance measurements and fault reports from the Virtualization Infrastructure Manager (616).

[0126] A virtualization infrastructure manager (616) can manage overall resources, such as appropriately distributing virtualized resources of the virtualization infrastructure (614) through specific reference points, and recovering and releasing distributed resources. The virtualized resources may include computing resources, storage and networking resources, and can collect and record information on performance or defects of the virtualized resources.

[0127] Network level (621) may include 3GPP network, local network, external network, etc.

[0128] A MEC platform based on the MEC framework described above can be included in the edge transfer environment of FIGS. 7 and 8.

[0130] FIG. 7 is a schematic diagram of an edge transfer environment showing an environment for an edge instance to be transferred to a target base station in an M2M system according to the present disclosure, and FIG. 8 is a diagram showing the edge transfer environment in more detail in an M2M system according to the present disclosure.

[0131] As an example, the environment for the edge transfer to occur may include a 3GPP network (700), and as shown in FIG. 8, may further include an M2M service platform (800) and an MEC service platform (801). Additionally, it may include one or more edge nodes (701, 702, 703, 704) and one or more mobile terminals (705).

[0132] In one embodiment, the 3GPP network (700) may be a core network designed in accordance with the specifications proposed by 3GPP and may support LTE and 5G, etc. In addition, it may include an Access Network Discovery and Selection Function (ANDSF), a Service Capability Exposure Function (SCEF), a System Architecture Evolution Gateway (SAE-GW), etc. In addition, it may notify a third party, including an M2M service platform, of a handover decision and may support a polling channel and other means to provide handover information. Furthermore, it may perform comprehensive management, such as managing and defining edge instances on a session basis, including M2M service instances including offloaded instances deployed at edge nodes.

[0133] In one embodiment, the one or more edge nodes (701, 702, 703, 704) may be conventional edge nodes and may be base stations including routers, access points, and eNBs, gNBs, and en-gNBs. Meanwhile, the edge nodes may be used in the sense of including fog nodes.

[0134] In one embodiment, the terminal (705) is a mobile device capable of internet connectivity, such as a vehicle or a smartphone.

[0135] In one embodiment, the M2M service platform (800) illustrated in FIG. 8 may refer to an M2M service central platform and may include common requirement functions necessary to configure M2M services, and individual services may be operated independently. Additionally, it may provide a function to transfer M2M service instances between edge nodes and may receive handover information from the 3GPP network. Also, in one embodiment, it may be a service central platform according to the oneM2M standard, may discover edge nodes, and may receive information related to handover from the 3GPP network.

[0136] Meanwhile, the application entity of the above M2M service platform ( <ae>) can store additional information as a resource about which resources were updated when an edge / fog instance is hosted on an edge node.

[0137] For example, whenever there is an update to an edge / fog instance, the M2M service platform determines which resources of the instance have been updated <modifiedresource>It can be recorded in resources and tracked.

[0138] In addition, this information can be used to transmit only modified resources to the target edge / fog node, thereby promoting data communication efficiency, and accordingly, the moved terminal can receive the same context-based services from the target edge / fog node.

[0139] As one embodiment, the MEC service platform (801) can be designed according to the MEC framework shown in FIG. 6 and can be involved in mobile edge computing of the edge node.

[0140] Edge transfer according to the present disclosure may be based on a handover from a source edge to a target edge that may occur to provide continuous and stable service as a terminal moves in an M2M system. In this case, the handover may be performed by the terminal directly or by an entity of the 3GPP network (700). In this case, the network entity may be, for example, ANDSF or SCEF, but is not limited thereto.

[0141] In one embodiment, one edge (701) among the edge nodes (701, 702, 703, 704) may be a source edge, and the other edge node (702) may be a target edge. Here, for example, the source edge and the target edge may be different base stations. It is assumed that the edge node (701) is in a state of accommodating various edge instances. In one embodiment, the edge node (701) may host service logic, including 3GPP network function virtualization instances and instances offloaded from M2M service platforms. It may also host various edge instances, such as M2M service platform instances.

[0142] At this time, the offloaded instance may refer to an instance offloaded from an M2M service platform (800) or another edge node for easy traffic processing.

[0143] In this case, in order to provide stable service to the terminal, when a handover occurs at the source edge, the 3GPP network function virtualization instance deployed at the source edge may be transferred to the target edge, which is another edge node (702). In this case, the M2M service instances at the source edge must also be transferred stably based on information collected from the 3GPP core network.

[0144] At this time, if Network Function Virtualization (NFV) or edge computing is possible, the edge instances can be transferred to the target edge, which is the edge node to which the terminal is newly connected.

[0145] According to the present disclosure, when a handover occurs, an edge transfer can be performed according to a Tightly Coupled Edge Mode or a Loosely Coupled Edge Mode.

[0146] According to the Loosely Coupled Edge Mode, during edge transfer, network function virtualization instances and M2M service instances hosted by the source base station can be independently transferred to the target edge node. Additionally, this may include cases where a handover occurs from a 3GPP 5G edge node to a 3GPP 5G edge node, and cases where a handover occurs from a 3GPP 5G edge node to a node that cannot host M2M service instances. In this case, the node that cannot host M2M service instances may be a non-3GPP edge node. This will be explained in more detail in FIGS. 9 to 14.

[0147] According to Tightly Coupled Edge Mode, both network function virtualization instances and M2M service instances are considered as edge instances, allowing them to be transferred non-independently to target edge nodes simultaneously. This will be explained in more detail in FIG. 15.

[0148] Meanwhile, edge transfer according to the present disclosure may be performed in various environments, but for clarity of explanation, it is assumed below that handover and edge transfer occur based on the environments of FIGS. 7 and 8. However, the present disclosure is not limited thereto.

[0150] First, as an example, a case where the source edge is a 3GPP 5G edge node and the target edge is also a 3GPP 5G edge node will be described.

[0151] FIG. 9 is a diagram showing a case where edge transfer is performed by a loosely coupled edge mode in an M2M system according to the present disclosure, and FIG. 10 is a diagram showing the edge transfer process in steps in an M2M system according to the present disclosure. More specifically, it relates to a case where edge instances including a network function virtualization instance and an M2M service instance at a source edge are transferred to a target edge independently of each other.

[0152] In one embodiment, the environment in which edge transfer takes place may include a mobile terminal (901), a source edge (902), a target edge (903), a 3GPP network (904), and an M2M service platform (905). Additionally, elements of the 3GPP network may include a Service Capability Exposure Function (SCEF), a System Architecture Evolution Gateway (SAE-GW), and an M2M service platform (905), and the source edge may be a source base station, and the target edge may be a target base station.

[0153] As shown in one embodiment of FIG. 9(a), the terminal can be connected to a 3GPP network via the source edge, and the 3GPP network and the M2M service platform can interact with each other, and as described above, an edge instance including a network function virtualization instance and an M2M service instance may be deployed at the source edge.

[0154] At this time, as an example embodiment, it is assumed that as the terminal moves, an entity of the 3GPP network, such as SCEF or ANDSF, rather than the terminal, makes a handover decision to the target edge. When a handover decision is made as in FIG. 9(b), the terminal may be notified of the handover decision (S1000). At this time, a tunnel for efficient data communication may be set up between the source edge and the target edge. The terminal may perform the handover (S1001) and connect with the target edge. In this case, the handover process may follow a conventional handover process and may follow a standard handover process proposed by 3GPP.

[0155] In one embodiment, the terminal may be separated from the source edge as shown in (c) of FIG. 9 and may receive services from the target edge. When the target edge performs edge transfer to provide services (S1002), the movement speed of the terminal must be taken into account to prevent service interruption and to prevent the quality of service from deteriorating. To this end, the network function virtualization instance of the source edge may first be replicated or transferred to the target edge using the set-up tunnel, and this process may be performed by a Network Functions Virtualization Orchestrator (NFVO) and may follow a conventional transfer process.

[0156] Once the transfer of the above network function virtualization instance is completed, handover information and the occurrence of the handover can be notified to the M2M service platform (S1003), and the M2M service platform may be a oneM2M service platform. Additionally, SCEF, MTC-IWF, or 5G SBA APIs of the 3GPP network may notify the M2M service platform of the terminal handover. Meanwhile, although not depicted in the drawing, if an MEC platform exists between the 3GPP network and the M2M service platform as shown in FIG. 8, this process may be triggered by the MEC platform. Furthermore, the handover information may include information regarding the target edge and the source edge, and may include information for a third-party entity, which will be described in detail below.

[0157] As an example, the edge instance of the source edge can be replicated and transferred to the target edge of the M2M service instance according to a data forwarding process, and the forwarding process may be a conventional data forwarding process including packet forwarding. This process may be included in the step (S1004) of performing the M2M service instance transfer of FIG. 10.

[0158] As illustrated in FIG. 9(d), once the edge transfer process is completed, the bearer of the source base station can be released through a path switch procedure. The source edge can improve efficiency by deleting the edge instance previously provided to the separated terminal. Additionally, if there was a connection or interaction between the M2M service instance and the network function virtualization instance, a connection update can be performed (S1005) as a new connection at the target edge may be required while performing the edge transfer.

[0159] Afterwards, the terminal can be notified that the transfer of the M2M service instance is completed (S1006). Accordingly, the terminal (901) can receive information from the target edge that is associated with the service associated with all edge instances and the M2M service instance.

[0160] Accordingly, the M2M service can be provisioned through the aforementioned target edge, the previously transferred network function virtualization instances, and the transferred M2M service instances. The resources being provisioned may include, for example, computing resources, storage, and network resources.

[0161] Meanwhile, the step (S1001) in which the terminal performs a handover may refer to the step of connecting to a target edge, and it has been depicted as being performed immediately after the terminal receives the handover decision. However, since this corresponds to one embodiment, it may also be performed after the transfer of the M2M service platform instance is known to the terminal, that is, after step S1006.

[0162] Meanwhile, as an example embodiment, one or more third-party entities other than the terminal may be connected to the target edge, and it is desirable for the third-party entities to be aware of the terminal's handover when they intend to transfer their application entities to the target edge. Accordingly, since it is desirable for the following information to be configured to be shared with or accessible to the third-party entities, the following information may be shared with the third-party entities during the step (S1001) in which the terminal performs a handover. However, the following information is an example embodiment and is not limited thereto.

[0163] 1. Whether the terminal handover process is performed

[0164] 2. Information on Source Edge and Target Edge

[0165] 3. Whether the above target edge supports application-level edge instance hosting (instance hosting capability of the above target edge)

[0166] 4. Location of the terminal performing the handover

[0167] 5. Movement path information of the above terminal

[0168] 6. Path plan or expected path of the above terminal

[0169] 7. Information on Network Function Virtualization (NFV) in Operation

[0171] FIG. 11 is a diagram illustrating a case in which an edge instance is transferred in a loosely coupled edge mode in an M2M system according to the present disclosure. More specifically, it is a diagram illustrating the edge transfer process from the perspective of an M2M terminal. Here, the terminal may refer to a terminal.

[0172] In one embodiment, according to the edge transfer process shown in FIGS. 9 and 10, as mentioned above, prior to the handover decision being made, the source edge may have been connected to the terminal and accommodated an edge instance associated with the terminal. As mentioned above, the edge instance may include an M2M service instance and a network function virtualization instance.

[0173] As mentioned above, in one embodiment, an edge instance is transferred in a loosely coupled edge mode, and the terminal can receive a handover decision when the handover is determined by elements of the 3GPP network, etc., rather than the terminal itself determining the handover (S1100). In addition, the edge instance of the source edge can be transferred to the target edge by the same edge transfer process mentioned above, and the terminal can be connected to the target edge that accommodates the transferred edge instance (S1101). At this time, the source edge and the target edge may correspond, for example, to edge nodes that support 5G according to 3GPP standards, and may follow the edge transfer process illustrated in FIGS. 9 and 10.

[0174] Meanwhile, although the present embodiment is illustrated as the terminal receiving a handover decision and performing a handover after the edge transfer is completed, according to other embodiments, it may be possible to perform a handover to the target edge before the edge transfer.

[0175] Meanwhile, according to the edge transfer process of FIGS. 9 and 10 above, a terminal may be connected to a single target edge. However, in the edge transfer process described with reference to FIGS. 13 and 14 below, there may be multiple target edges, and for clarity in distinguishing and explaining each, they may be referred to as a target edge and an M2M edge node. In this case, the target edge and the M2M edge node may be different base stations, Road Side Units, Smart Building Access Points, etc.

[0177] FIG. 12 is a diagram showing an edge transfer process according to a weakly coupled edge mode in an M2M system according to the present disclosure, wherein the edge transfer process is a diagram showing the edge transfer process described in FIG. 9 and 10 from the perspective of a target edge.

[0178] In one embodiment, the target edge may recognize a terminal handover decision determined by the terminal or the 3GPP network (S1200). This may be recognized by setting up a tunnel with the source edge, but may also be recognized through the source edge or other 3GPP network elements.

[0179] Once the handover decision is recognized, the target edge can accommodate network function virtualization instances of the source edge (S1201) and M2M service instances (S1202) by replicating or moving edge instances of the source edge to the target edge through a tunnel set up with the source edge, and this process can be carried out by the same transfer process as mentioned above.

[0180] Once both the network function virtualization instance and the M2M service instance are transferred, they can be connected to the terminal for which the handover has been determined (S1203). Meanwhile, although the above process is illustrated in this drawing as being connected to the terminal after all edge transfer processes, since this is an embodiment, it is possible to connect to the terminal immediately after recognizing the handover decision.

[0182] FIG. 13 is a diagram illustrating an edge transfer process according to a loosely coupled edge mode in an M2M system according to the present disclosure, and FIG. 14 is a diagram illustrating the edge transfer process in steps. More specifically, it relates to an edge transfer process based on a handover from a 3GPP 5G edge node to an edge node that cannot host an M2M service instance. In this case, the edge node that cannot host the M2M service instance may be a non-3GPP 5G edge node.

[0183] In one embodiment, the environment in which edge transfer takes place may include a mobile terminal (1301), a source edge (1302), a target edge (1303), a 3GPP network (1304), an M2M service platform (1305), and an M2M edge (1306). Additionally, elements of the 3GPP network may include a Service Capability Exposure Function (SCEF) and a System Architecture Evolution Gateway (SAE-GW), the source edge may be a source base station, and the target edge may be a target base station.

[0184] Unlike the loosely coupled edge mode of FIGS. 9 and 10 above, when the target edge node is a non-3GPP 5G edge node, the edge most suitable for transferring network function virtualization instances and the edge most suitable for transferring M2M service instances may differ, so an additional process may be required.

[0185] In one embodiment, according to FIG. 13(a), it is assumed that as the terminal (1301) moves, an entity of the network, such as SCEF or ANDSF, makes a handover decision to the target edge (1303). When the handover decision is made, the terminal (1301) may be notified (S1400). Accordingly, the terminal may perform the handover (S1401) and connect with the target edge (1303). In this case, the handover process may follow a conventional handover process and may follow a standard handover process proposed by 3GPP.

[0186] Subsequently, according to FIG. 13(b), the terminal can be separated from the source edge (1302) and perform edge transfer to receive services from the target edge (S1402). It is desirable to perform edge transfer considering the movement speed of the terminal in order to prevent service interruption and to prevent the service quality from deteriorating. To this end, the network function virtualization instance of the source edge can first be replicated or moved to the target edge by the Network Functions Virtualization Orchestrator (NFVO), and can be done through a normal transfer process.

[0187] Once the above process (S1402) is completed, handover information and the occurrence of the handover can be notified to the M2M service platform (1305) (S1403), and the M2M service platform may be a oneM2M service platform. Additionally, the above process may be performed by SCEF, MTC-IWF, or 5G SBA APIs of the 3GPP network (1304). The handover information may include information regarding the target edge and the source edge. Furthermore, information for the third-party entity described above may also be included. Meanwhile, if the MEC platform exists as shown in FIG. 8, this process may be triggered by the MEC platform.

[0188] Subsequently, the M2M service platform (1305) can determine the optimal M2M edge node (1306) for transferring the M2M service instance through exploration (S1404), and the optimal M2M edge node can be explored based on DNS, Registry, or mDNS, etc. At this time, even if the target edge to which the network function virtualization instance is transferred has been determined as the optimal target edge based on the distance from the terminal and signal strength, the target edge (1303) may not support hosting the M2M service instance. In this case, it may be necessary for the M2M service platform to determine the M2M edge node, and this may be determined based on exploration. The M2M edge node (1306) may be a Road Side Unit, a Smart Building Access Point, etc. However, it is not limited thereto.

[0189] Subsequently, as shown in FIG. 13 (c), the M2M service platform can replicate and transfer the M2M service instance of the source edge to a determined optimal M2M edge node (S1405). The M2M edge node may be directly connected to the M2M service platform. The M2M service instance may include an instance offloaded from the M2M service platform. At this time, the offloaded instance may be the same as mentioned above.

[0190] Meanwhile, in FIG. 13 (c), the M2M service platform (1305) is shown replicating and transferring the M2M service instance of the source edge (1302), but since this is an embodiment, if an interface capable of direct data transmission and reception between edge nodes is implemented, it may also be possible to transfer directly from the source edge to the target edge node.

[0191] Afterwards, as shown in (d) of FIG. 13, edge instances existing at the source edge are removed, and the transfer of the M2M service instance can be notified to the terminal (S1406). Information about the updated M2M service platform and M2M service instance can be transmitted to the terminal.

[0192] Meanwhile, if the target edge to which the network function virtualization instance has been transferred supports M2M service instance hosting, the M2M edge node may be the same as the target edge, and in this case, the M2M service instance can be transferred to the target edge to perform the same process as FIGS. 9 and 10.

[0193] Meanwhile, although the above embodiment was described as if the M2M edge node and the target edge were connected to different base stations, according to other embodiments, the M2M edge node and the target edge can both be wirelessly connected to the same base station, so it is not limited thereto.

[0195] FIG. 15 is a step-by-step diagram illustrating the process of edge transfer in a tightly coupled edge mode in an M2M system according to the present disclosure. More specifically, it is a diagram illustrating that edge instances of a source edge are transferred to a target edge non-independently.

[0196] In one embodiment, it is assumed that the 3GPP network is aware of third-party entity information, and that the source edge and target edge have the ability to manage all edge instances.

[0197] In one embodiment, the 3GPP network first determines the handover of the terminal and can notify the moving terminal of this (S1500). Accordingly, the terminal performs the handover (S1501), is separated from the source edge, and can be connected to the target edge. When the edge instance is transferred in a tightly coupled edge mode, the edge instance including the M2M service instance and the network function virtualization instance can all be transferred to the target edge at once (S1502), and this process can be carried out simultaneously. In addition, the source edge and the target edge may correspond to edge nodes including different 3GPP 5G base stations. When the edge transfer is completed, the fact of completion may be notified or shared with the corresponding respective platforms and networks (S1503). For example, the completion of the transfer may be notified to the M2M service platform or MEC platform, etc.

[0198] Accordingly, the terminal can reliably receive services from the target edge even if a handover occurs.

[0200] FIG. 16 is a diagram showing the configuration of an M2M device in an M2M system according to the present disclosure.

[0201] Referring to FIG. 16, the M2M device (1610) may include a processor (1612) that controls the device and a transceiver (1614) that transmits and receives signals. In this case, the processor (1612) may control the transceiver (1614). Additionally, the M2M device (1610) may communicate with another M2M device (1620). The other M2M device (1620) may also include a processor (1622) and a transceiver (1624), and the processor (1622) and the transceiver (1624) may perform the same functions as the processor (1612) and the transceiver (1614).

[0202] For example, the aforementioned transmitter and receiver may each be one of the M2M devices (1610 and 1620) of FIG. 16. Additionally, the devices (1610 and 1620) of FIG. 16 may be other devices. For example, the devices (1610 and 1620) of FIG. 16 may be devices such as a terminal, terminal, device, vehicle or base station, or a device located on an M2M service platform that performs communication. That is, the devices (1610 and 1620) of FIG. 16 refer to devices capable of performing communication and are not limited to the embodiments described above.

[0203] The various embodiments of the present disclosure are not intended to list all possible combinations but to describe representative aspects of the present disclosure, and the matters described in the various embodiments may be applied independently or in combination of two or more.

[0204] Furthermore, various embodiments of the present disclosure may be implemented by hardware, firmware, software, or combinations thereof. In the case of implementation by hardware, it may be implemented by one or more ASICs (Application Specific Integrated Circuits), DSPs (Digital Signal Processors), DSPDs (Digital Signal Processing Devices), PLDs (Programmable Logic Devices), FPGAs (Field Programmable Gate Arrays), general processors, controllers, microcontrollers, microprocessors, etc. For example, it is obvious that it may be implemented in the form of a program stored on a non-transient computer-readable medium that can be used at the end or edge, or in the form of a program stored on a non-transient computer-readable medium that can be used at the edge or cloud.

[0205] The scope of the present disclosure includes software or machine-executable instructions (e.g., an operating system, an application, firmware, a program, etc.) that enable an operation according to a method of various embodiments to be executed on a device or computer, and a non-transitory computer-readable medium on which such software or instructions, etc. are stored and which is executable on a device or computer.

[0206] As described above, the detailed description of the preferred embodiments of the present invention disclosed is provided to enable those skilled in the art to implement and practice the present invention. Although the above description refers to preferred embodiments of the present invention, those skilled in the art will understand that various modifications and changes can be made to the present invention without departing from the spirit and scope of the present invention as described in the following claims. Accordingly, the present invention is not intended to be limited to the embodiments shown herein, but to be given the broadest possible scope consistent with the principles and novel features disclosed herein. Furthermore, although preferred embodiments of the present specification have been illustrated and described above, the present specification is not limited to the specific embodiments described above, and various modifications can be made by those skilled in the art without departing from the gist of the present specification as claimed in the claims, and such modifications should not be understood individually from the technical spirit or perspective of the present specification.

[0207] In addition, both product inventions and method inventions are described in this specification, and the descriptions of both inventions may be applied supplementarily as necessary.

[0208] Furthermore, the present invention has been described with reference to its preferred embodiments. Those skilled in the art will understand that the present invention may be implemented in modified forms without departing from the essential characteristics of the invention. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the invention is defined by the claims, not by the foregoing description, and all variations within the scope of the claims should be interpreted as being included in the invention. Explanation of the symbols

[0210] 1610: M2M device 1612: Transmitter / Receiver 1614: Processor 1620: M2M device 1622: Transmitter / Receiver 1624: Processor< / modifiedresource> < / ae> < / modifiedresource> < / group> < / groupannc> < / container> < / containerannc> < / resourcetype> < / resourcetype> < / modifiedresource> < / modifiedresource>

Claims

Claim 1 A method of operation of an M2M device in a Machine-to-Machine (M2M) system, comprising: a step of recognizing the occurrence of a handover from a network and receiving handover information when a network function virtualization instance of a source edge is transferred to a target edge; and a step of replicating an M2M service instance of the source edge and transferring it to an M2M edge node; wherein the network function virtualization instance and the M2M service instance are transferred independently based on the characteristics of the target edge, and the source edge is an edge node supporting 3GPP 5G, and if the target edge cannot host the M2M service instance, a separate M2M edge node is searched for to transfer the M2M service instance. Claim 2 delete Claim 3 delete Claim 4 A method of operation of an M2M device according to claim 1, wherein the connection between the M2M service instance and the network function virtualization instance is updated after the M2M service instance is transferred. Claim 5 A method of operation of an M2M device according to claim 1, characterized in that the M2M edge node is a Road Side Unit or a Smart Building Access Point. Claim 6 A method of operation of an M2M device according to claim 1, characterized in that the search is performed based on at least one of DNS, Registry, and mDNS. Claim 7 A method of operation of an M2M device according to claim 1, wherein the handover information comprises at least one of information regarding the source edge and the target edge, the location of the terminal, information regarding the path traversed and the expected path of the terminal, and the instance hosting capability of the target edge. Claim 8 In claim 1, information regarding the transfer of the M2M service instance and the network function virtualization instance, and the updated connection, is <modifiedresource> A method of operation of an M2M device characterized by being recorded in a resource.< / modifiedresource> Claim 9 A method of operation of an M2M device according to claim 1, characterized in that the M2M service instance includes an offloaded instance. Claim 10 An M2M device in an M2M (Machine-to-Machine) system comprises: a transceiver for transmitting and receiving data; and a processor for controlling the transceiver; wherein the processor receives information regarding the handover when a terminal handover occurs, and when a network function virtualization instance of a source edge is transferred to a target edge, transfers an M2M service instance to an M2M edge node, wherein the network function virtualization instance and the M2M service instance are transferred independently based on the characteristics of the target edge, and wherein the processor searches for a separate M2M edge node to transfer the M2M service instance when the source edge is an edge node supporting 3GPP 5G and the target edge cannot host the M2M service instance. Claim 11 delete Claim 12 delete Claim 13 An M2M device characterized in that, in claim 10, when the M2M service instance is transferred, the connection between the M2M service instance and the network function virtualization instance is updated. Claim 14 An M2M device according to claim 10, characterized in that the M2M edge node is a Road Side Unit or a Smart Building Access Point. Claim 15 An M2M device according to claim 10, characterized in that the search is performed based on at least one of DNS, Registry, and mDNS. Claim 16 An M2M device according to claim 10, wherein the handover information comprises at least one of the following: information regarding the source edge and the target edge; the location of the terminal; information regarding the path traversed and the expected path of the terminal; and the instance hosting capability of the target edge. Claim 17 In claim 13, information regarding the transfer and updated connection of the M2M service instance and the network function virtualization instance is, <modifiedresource> M2M device characterized by being recorded in a resource.< / modifiedresource> Claim 18 An M2M device according to claim 10, wherein the M2M service instance includes an offloaded instance. Claim 19 An M2M terminal (M2M device) in a Machine-to-Machine (M2M) system comprises: a transceiver for transmitting and receiving data; and a processor for controlling the transceiver; wherein the processor receives a handover decision and connects to a target edge that accommodates a transferred edge instance, wherein the edge instance includes an M2M service instance and a network function virtualization instance, and the M2M service instance and the network function virtualization instance are transferred independently based on the characteristics of the target edge, wherein the source edge is an edge node supporting 3GPP 5G, and if the target edge cannot host the M2M service instance, the M2M service instance is transferred to a separate M2M edge node.

Images