Method and apparatus for service layer charging association with underlying network

Abstract

The present disclosure relates to methods and apparatus for service layer charging association with an underlying network. A mechanism for service layer charging association is disclosed. Embodiments may include a service domain charging association function (SD-CCF) that is responsible for interacting with the underlying network at the service layer and associating charging information. Charging association information may be used to implement and facilitate the service layer charging association.

Description

[0001] This application is a divisional application of the PCT application entering the Chinese national phase, whose international application date is October 27, 2015, national application number is 201580065412.6, and invention name is “Method and device for associating service layer billing with underlying network”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims priority to U.S. Provisional Patent Application No. 62 / 069,464, filed on October 28, 2014, the disclosure of which is incorporated herein by reference in its entirety. Background Art

[0004] The 3rd Generation Partnership Project (3GPP) covers cellular telecommunication network technologies, including: radio access, core transport network, and service capabilities. The latest version of the 3GPP Mobile Core Network (MCN) architecture for wireless communications is called the Evolved Packet Core (EPC). The Evolved Packet Core (EPC) has a "flat architecture" to efficiently handle data flows from a performance and cost perspective. The EPC also separates user data (also known as the user plane) from signaling (also known as the control plane) to make the EPC scale independent.

[0005] The 3GPP Network Policy and Charging Control (PCC) system provides dynamic control of policies and charging per subscriber and per IP data flow. It supports better QoS control so that application servers can dynamically control the quality of service (QoS) and charging policies of the delivered services.

[0006] Figure 11 is a schematic diagram illustrating a PCC architecture 100 consisting of several functions with specified interfaces between them. Policy and Charging Rules Function (PCRF) 102 is responsible for managing policies and charging for IP-CAN sessions, IP-CAN bearers, or service data flows (SDFs). Policy and Charging Enforcement Function (PCEF) 104 contains service data flow detection, policy enforcement, and flow-based charging functions. 3GPP networks support both offline charging and online charging. Offline Charging System (OFCS) 106 is a mechanism in which charging information does not affect the presented services (such as postpaid subscribers) in real time. OFCS 106 includes Charging Data Function (CDF) and Charging Gateway Function (CGF). CDF uses information received from Charging Trigger Function (CTF) to build Charging Data Record (CDR). CGF acts as a gateway between the 3GPP network and the accounting domain to transmit CDR. In contrast, Online Charging System (OCS) 108 performs charging functions, such as real-time credit control. This enables OCS 108 to influence service execution in real time, typically for prepaid subscribers.3GPP networks support various charging models such as volume-based charging, time-based charging, volume and time-based charging, event-based charging, and no charging.

[0007] From the perspective of the protocol stack, the service layer is usually located above the application protocol layer and provides value-added services to client applications. Therefore, the service layer is usually classified as a "middleware" service. For example, Figure 2 is a schematic diagram illustrating an exemplary service layer 202 between an IP network stack 204 and an application 206 .

[0008] The M2M / IoT service layer is an example of a type of service layer specifically targeted at providing value-added services to M2M / IoT type devices and applications. Recently, multiple industry standard bodies (e.g., oneM2M) have developed the M2M / IoT service layer to address challenges associated with integrating M2M / IoT type devices and applications into deployments such as the Internet / Web, cellular, enterprise, and home networks.

[0009] The M2M service layer can provide applications and devices with access to a set of M2M-oriented capabilities supported by the service layer. Some examples include security, billing, data management, device management, discovery, provisioning, and connectivity management. These capabilities are available to applications via APIs that utilize message formats, resource structures, and resource representations defined by the M2M service layer.

[0010] oneM2M is a new standard for developing technical specifications that address the need for a common M2M service layer that can be easily embedded within a variety of hardware and software and that can be relied upon to connect various devices in the field with M2M application servers worldwide.

[0011] Figure 3 is a schematic diagram illustrating a oneM2M public service layer 302 supporting a set of public service functions (CSFs) (i.e., service capabilities). An instantiation of a set of one or more specific types of CSFs is referred to as a public service entity (CSE) 304, which can be hosted on different types of network nodes (e.g., infrastructure nodes, intermediate nodes, dedicated nodes).

[0012] oneM2M is developing the service layer following two architectural approaches. Figure 4 is a schematic diagram illustrating the ROA (Resource Oriented Architecture) architecture for oneM2M. A resource is a uniquely addressable element in the architecture with a representation that can be manipulated via RESTful methods such as create, retrieve, update, and delete. These resources are made addressable by using Universal Resource Identifiers (URIs). A resource can contain (multiple) sub-resources and (multiple) attributes. A child resource is a resource that has a containment relationship with a parent resource. A parent resource representation contains references to its (multiple) child resources. The lifecycle of a child resource is limited by the resource lifecycle of the parent resource. Each resource supports a set of "attributes" that store information about the resource.

[0013] Figure 5 is a diagram illustrating SoA (Service Oriented Architecture) for oneM2M. The SoA architecture is being developed to take into account legacy deployments that are not RESTful based. The SoA architecture primarily reuses the same service layer functional architecture. The service layer contains various M2M services and multiple services can be grouped into service components. In addition to the existing reference points, the SoA architecture introduces an inter-service reference point Msc. The communication between M2M service components through the Msc reference point utilizes web service methods, for example, web service message exchange pattern (MEP).

[0014] See again Figure 3 The Mcn reference point is designed for communication flows between a Common Service Entity (CSE) 304 and an underlying Network Service Entity (NSE) 306. These flows enable the CSE 304 to use the supported services provided by the underlying NSE 306 (in addition to transport and connectivity services).

[0015] The communication between CSE 304 and NSE 306 across the Mcn reference point includes:

[0016] CSE access network service functions provided by the underlying network; and

[0017] Optimize network service processing of the underlying network.

[0018] Such services are usually more than just general transport services.

[0019] Communications to the underlying network through the Mcn reference point include:

[0020] • Messaging services that are widely deployed by applications and network operators using several existing mechanisms.

[0021] • Use of network APIs defined by other SDOs (eg OMA and GSMA) by network operators for their services.

[0022] • The interconnection of MTC (Machine Type Communication) for services and security aspects has been defined by 3GPP networks.

[0023] The Service Charging and Accounting (SCA) CSF 308 defined by oneM2M is responsible for handling all charging and accounting issues. Table 1 shows the charging requirements related to charging association, however, the current oneM2M specification does not fully address these requirements.

[0024] Table 1: oneM2M requirements for billing association

[0025] Summary of the invention

[0026] A mechanism for service layer charging association is disclosed. The exemplary mechanism describes how the service layer interacts with the underlying network for charging association information and how charging association at the service layer is performed.

[0027] Embodiments may include a service domain charging correlation function (SD-CCF) that is responsible for interacting with the underlying network and correlating charging information at the service layer. Charging correlation information may be used to implement and facilitate service layer charging correlation. The procedures of the SD-CCF may be used to interact with the underlying network to facilitate charging correlation at the service layer.

[0028] The oneM2M embodiment shows how the proposed SD-CCF can cooperate with the 3GPP network to perform service layer charging association. Existing service layer charging does not include any mechanism to perform charging association at the service layer. Specifically, existing service layer charging does not have a mechanism to obtain charging-related information for association from the underlying network and how to perform charging association at the service layer.

[0029] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] A more detailed understanding may be obtained through the following description given by way of example in conjunction with the accompanying drawings, in which:

[0031] Figure 1 is a schematic diagram illustrating the 3GPP network policy and charging control (PCC) architecture.

[0032] Figure 2 is a schematic diagram illustrating an exemplary service layer between an IP network stack and an application.

[0033] Figure 3 is a schematic diagram illustrating the oneM2M common services layer supporting a set of common services functions (CSFs) (ie, service capabilities).

[0034] Figure 4 is a schematic diagram illustrating a ROA (Resource Oriented Architecture) architecture for oneM2M.

[0035] Figure 5 is a schematic diagram illustrating SoA (Service Oriented Architecture) for oneM2M.

[0036] Figure 6 It is a schematic diagram of the architecture of the service domain billing system.

[0037] Fig. 7A -B is a schematic diagram illustrating an exemplary message exchange process between the 3GPP network and the service layer.

[0038] Figure 8 It's a picture. <eventconfig>Resources and <statscollect>Schematic diagram of the resource.

[0039] Fig. 9 is a schematic diagram illustrating an exemplary architecture of one embodiment.

[0040] Fig.10 is a flow chart illustrating the problems of existing billing systems.

[0041] Fig.11 is a diagram illustrating that a Service Domain Charging Correlation Function (SD-CCF) may be hosted within an M2M service layer instance.

[0042] Fig.12 is a flow chart illustrating a process for creating a new charging association rule in one embodiment.

[0043] Fig.13 is a flow chart illustrating a message exchange process for charging policy association for one embodiment.

[0044] Fig.14 is a flow chart illustrating a message exchange process for facilitating charging information correlation.

[0045] Fig.15 is a flow chart illustrating an exemplary method for performing service-tier charging correlation.

[0046] Fig.16 is a schematic diagram illustrating an exemplary embodiment for implementing the proposed SD-CCF as a part of Service Charging & Settlement (SCA) CSF based on the oneM2M functional architecture.

[0047] Fig.17 It's a picture. <chargingcorrelationrule>Schematic diagram of the resource.

[0048] Fig.18 It's a picture. <chargingcorrelationtrigger>Schematic diagram of the resource.

[0049] Fig.19 is a schematic diagram illustrating an exemplary embodiment associated with a oneM2M charging policy of a 3GPP network.

[0050] Fig. 20 is a schematic diagram illustrating an exemplary embodiment associated with oneM2M charging information for a 3GPP network use case.

[0051] Fig.21 is a schematic diagram illustrating an embodiment of the proposed SD-CCF 1102 in the oneM2M SoA architecture.

[0052] Fig.22A is a schematic diagram of an example machine-to-machine (M2M) or Internet of Things (IoT) communication system in which one or more disclosed embodiments of the IoT event management system and method may be implemented.

[0053] Fig. 22B Yes, you can Fig.22A A system diagram of an example architecture for use within an M2M / IoT communication system is illustrated in FIG.

[0054] Fig. 22C Yes, you can Fig.22A A system diagram of an example M2M / IoT terminal or gateway device used in a communication system illustrated in FIG.

[0055] Fig.22D It can be reflected in Fig.22A A block diagram of an example computing system that implements various aspects of a communication system.

[0056] Fig.23A -B is a schematic diagram illustrating an exemplary interface of one embodiment. DETAILED DESCRIPTION

[0057] Figure 6 606 receives offline charging events from SD-CM 604 and generates service domain charging data records (SD-CDRs). Service domain online charging system (SD-OCS) 608 receives service requests, checks credits, and grants services. SD-OCS 608 can maintain credit information for different service subscribers.

[0058] Fig. 7A -B is a diagram illustrating the 3GPP network and service layer (i.e., Figure 6 Schematic diagram of an exemplary message exchange process between SD-CS 602 shown in FIG. The process shown in the figure does not need to occur in the order shown in the figure. This interaction provides more comprehensive billing between the 3GPP network and the service domain.

[0059] exist Fig. 7A In steps 1-4 of -B, in one deployment scenario, the 3GPP network charging system may be under the control of SD-CS 602. 3GPP network charging policy entity PCRF 702 sends charging policy configuration for SD-CS 602 via the Rx reference point. SD-CS 602 configures its charging policy based on input from the 3GPP network charging system.

[0060] Fig. 7A -B steps 5-8 show an example of MTC-IWF 704 sending 3GPP network charging information to SD-CS 602 via the Tsp reference point. For example, MTC-IWF 704 has 3GPP subscriber information, and SD-CS 602 can associate the 3GPP network ID with the service domain ID.

[0061] exist Fig. 7A In steps 9-12 of -B, PCRF 702 may pass information related to 3GPP network charging (such as session status) to SD-CS 602. SD-CS 602 takes action according to its policy. For example, when a 3GPP network session has been switched to another access technology, SD-CS 602 may apply a different rate.

[0062] exist Fig. 7A -B, in another embodiment, SD-CS 602 may be in control of the message exchange, wherein SD-CS 602 may attach the service domain charging information in the service domain operation message to PCEF 706 via the user plane reference point Gi / SGi. Charging is performed at PCEF 706, and the information is sent back to SD-CS 602 via the user plane, and PCRF 702 may be updated accordingly by PCEF 706 if necessary.

[0063] To understand, execution Fig. 7A -B is a logical entity that can be stored in a node, device, server or other computer system (such as Fig. 22C or Fig.22D The logical entity may be implemented in the form of software (i.e., computer executable instructions) in a memory of a computer system (e.g., one of the computer systems illustrated in FIG. 1 ) and executed on a processor of the node, device, server, or other computer system. That is, the logical entity may be implemented in the form of software (i.e., computer executable instructions) stored in a computing device (e.g., Fig. 22C or Fig.22D The present invention is implemented in the form of software (i.e., computer executable instructions) in the memory of the device or computer system shown in FIG. Fig. 7A -B, the computer executable instructions when executed by the processor of the computing device perform Fig. 7A It should also be understood that the steps illustrated in FIG. 1 and 1 may be performed by the communication circuitry of the node under the control of the processor of the node and the computer executable instructions (eg, software) executed by it. Fig. 7A -B. In addition, Figure 8 As shown, the current oneM2M specification defines <eventconfig>Resource 802 and <statscollect>Resource 804 is used to record and maintain billing policies and billing record information respectively. Specifically, <eventconfig>Resource 802 uses the detailed information to maintain the billable event; and <statscollect>Resource 804 maintains a specific charging policy using attributes that indicate characteristics of the charging policy.

[0064] 3GPP networks introduce the concept of charging association in some specifications. In one embodiment, charging data association is defined as combining charging events generated by a charging trigger function (CTF) when they belong to the same bearer / session / service resource usage. Association provides association of charging information for resource usage of mobile subscribers. In addition, the concept of inter-operator identification (IOI) is introduced for inter-network association to enable different operators involved in an IMS session to identify each other.

[0065] In another specification, the charging association between the 3GPP core network and the IMS is discussed. However, the association here only focuses on the ID mapping / association across the two networks.

[0066] The Open Mobile Alliance (OMA) defines the concept of charging correlation: Correlation can occur between charging events generated by different entities, while these charging events are collaborating to provide a single service. The correlation function can provide the correlation of events to the subscriber / application to be charged. Within the OMA perspective, the correlation focuses on charging operations rather than inter-network correlation.

[0067] Service layer charging correlation is a broad concept to dynamically adjust service layer charging behavior based on charging correlation information provided by the underlying network.

[0068] The service provider charges the service subscriber based on the transactions related to the service layer operations (e.g., sensor data reading, data retrieval); while the underlying network charges the service subscriber based on the transmission of the data stream. The operations at the two layers are interrelated, for example, a data retrieval operation at the service layer also involves data transmission at the underlying transport layer. Therefore, it is necessary for the service layer and the underlying network to correlate the same billing-related information.

[0069] like Fig. 9 As shown, a service provider (Company A) provides a home surveillance service 902 through its service layer platform 904. A service subscriber, when away from home, wishes to monitor his house using an application installed on a user equipment (UE) 906 (such as a cell phone or tablet) via cameras 908 fixed inside and outside the house. In the case where the service subscriber requests image / video transmission from the camera 908 through his cell phone 906, the camera 908 may automatically start transmitting the image / video captured by the camera 908. In the case where there is an abnormal (e.g., intruder) image captured by the camera, the camera 908 may also be able to initiate an audio / video call or send a message for alarm processing to the cell phone 906 of the service subscriber.

[0070] The service provider (i.e., Company A) wishes to perform billing separate from the underlying access network. The service subscriber pays a monthly service subscription fee, which includes, for example, free 1 Gigabit of data for transmitting images / videos through the 3GPP network 910. The service provider bears the cost of 3GPP network data based on the agreement with the 3GPP network supplier. Once the amount of data exceeds 1 Gigabit, the service provider will pay an additional fee to the 3GPP network supplier and charge the service subscriber accordingly. This new billing model is called data connectivity for initiation, which is included in the latest 3GPP version. The initiator (e.g., service provider) bears the cost of the subscriber's data usage so that the subscriber can access the service provider's services. This new model (data connectivity for initiation) provides additional revenue opportunities for both the service provider and the 3GPP network operator. In addition, the 3GPP network 910 performs data flow-based billing. In other words, different prices are applied based on QoS (in this case, data rate), that is, higher data rate flows are more expensive than lower data rate flows. The 3GPP network 910 reports the dynamic change in the transmission data rate to the service provider so that the service provider can adjust the service layer charging price applied to the service subscriber accordingly.

[0071] In this case, the 3GPP network 910 should notify the service provider when the service subscriber reaches the data volume threshold, so that the service provider can start charging the service subscriber additional fees. In addition, the 3GPP network 910 needs to report the change of the flow data rate so that the service subscriber can access the service. Unfortunately, there is no mechanism defined for the service layer 904 to dynamically adjust the service layer charging behavior according to the events occurring in the underlying network 910. In this case, since the service provider does not know when the threshold is reached, the service provider will not charge the service subscriber additional fees. In addition, since the service provider cannot be informed of the change of the service data rate in the underlying network (due to the lack of dynamic charging reporting / configuration), the service provider will always apply the same price to the service subscriber for the data rate in the underlying network. Note that the policy and charging enforcement function (PCEF) 912 in the 3GPP network 910 is the main entity for monitoring these activities; it will contact the policy and charging rules function (PCRF) 914, which then reports to the service layer entity.

[0072] Fig.10 is a flow chart showing the problems of the existing charging system. In problem 1, there is no mechanism to report the event of service layer charging after the flow data rate changes. In problem 2, there is no mechanism to report the event of service layer charging after reaching the threshold of the amount of data to be sent.

[0073] The service provider charges the service subscriber based on transactions related to the service layer operations (e.g., sensor data reading, data retrieval); while the underlying network 910 charges the service subscriber based on the transmission of the data stream. The operations at the two layers are interrelated, for example, a data retrieval operation at the service layer may also involve data transmission at the underlying transport layer. Therefore, it is necessary for the service layer and the underlying network to correlate the same information related to billing.

[0074] More specifically, billing association is required when the service provider and the underlying network operator are different business units. Even if the service provider and the underlying network operator belong to the same business unit, there may be two billing systems, one for transmitting data in the underlying network 910 and the other for service layer transactions. This is because services can be provided through different underlying networks; and the underlying network 910 can transmit data streams for different service layer platforms (i.e., service providers). For example, regardless of the type of underlying network used to access the cloud infrastructure, the service provider provides cloud services and collects service layer billing records. In addition, the use case introduced below shows that, using billing-related information from the 3GPP network 910, the service layer 904 can dynamically adjust the billing operation based on the billing policy changes or some specific trigger events that occur in the 3GPP network 910, thereby enabling the service provider to complete more accurate and efficient billing.

[0075] However, there is no general mechanism for the service layer 904 to request any charging association information from the underlying network entity and adjust the service layer behavior based on the information obtained from the underlying network 910 (e.g., PCRF 914 in the 3GPP network 910, Policy Enforcement Point (PEP) in the Broadband Forum (BBF) fixed network) for performing charging at the service layer 904. Moreover, the existing service layer does not support associated charging information at the service layer (i.e., charging association information defined later). This lack of function may cause some problems.

[0076] Service layer billing is inaccurate. Specifically, the service provider cannot dynamically adjust the service layer billing behavior (e.g., capture new billable events, apply new billing rates) in response to billing policy changes or triggering events that occur in the underlying network. In other words, the service layer 904 does not support a mechanism to adjust billing behavior based on notifications from the underlying network 910. This may result in underbilling or overbilling of service subscribers. For example, in Fig. 9 In the use case of , if the service provider does not get notification from the 3GPP network 910 that the data volume threshold has been reached, it cannot start charging additional charges to the service subscriber in addition to the monthly fee.

[0077] Existing systems add information exchange overhead for accurate service layer billing. In the absence of a billing association mechanism at the service layer 904, the service provider must rely on the underlying network billing system by passing the service layer billing information down to the underlying network 910. This requires frequent communication between the service layer 904 and the underlying network to exchange service layer billing information, especially for M2M deployments, where there may be a large number of devices and applications running on the service layer 904. Therefore, it is not efficient to pass service layer billing records to the underlying network. Specifically, the service layer 904 needs to continuously pass the service layer CDR to the underlying network. The underlying network 910 mediates / processes the service layer CDR by considering the associated information in the underlying network, and then passes these service layer CDRs to the accounting system. Compared with the underlying network only sending information related to billing to facilitate the associated operations performed at the service layer, this generates more message exchange overhead between the network and the service layer 904.

[0078] Additional complexity is added to the underlying network 910. The underlying network 910 must be able to interpret the service layer charging information passed to it. This requires an underlying network with the ability to handle various types of charging information, especially since there may be a large number of devices and applications running in the service layer 904. By having the service layer 904 perform the charging and then pass the results down to the underlying network 910, the underlying network charging function does not need to know such things as the service layer charging policy, the service layer charging information, the format of the service layer CDR, etc.

[0079] Current solutions mainly assume that the underlying network 910 (e.g., 3GPP network) governs the charging operations (i.e., the service layer 904 passes the charging-related information to the underlying network, which is responsible for integrating / mediating the charging information for both the service layer and the underlying network). The current service layer standard development organization (SDO) (e.g., oneM2M) does not define any mechanism for facilitating service layer 904 charging by correlating the charging information from the underlying network 910. There is no mechanism defined for service providers that can correlate the charging information from the underlying network 910 (e.g., 3GPP network) to achieve more accurate and efficient charging performed at the service layer. Existing service layer charging solutions (e.g., Figure 6 and Fig. 7A - B) Some interactions between the underlying network and the service layer are defined; however, there is no mechanism to address the operation of correlating charging information at the service layer when specific charging information is obtained from the underlying network.

[0080] Service domain charging correlation is disclosed below as an operation to dynamically adjust service layer charging behavior based on charging correlation information provided by the underlying network.

[0081] To support dynamic charging operations, the service domain charging correlation function (SD-CCF) 1102 may perform, but is not limited to, some or all of the following types of functions: managing service layer charging correlation rules, interacting with underlying networks, and performing service layer charging correlation.

[0082] Managing (creating, updating, and deleting) service layer charging association rules can facilitate service layer charging association. Specifically, SD-CCF 1102 can receive a request to create / update / delete charging management rules from an entity (e.g., charging service capability, application) and then perform the desired operation.

[0083] Interaction with the underlying network can configure charging association triggers in the underlying network that can affect service layer billing operations. As defined later, the charging association trigger occurs at the underlying network 1106 and can reflect the billing policy or billing information in the underlying network 1106. This function is implemented by exchanging messages between the SD-CCF 1102 and the underlying network entities. Specifically, the SD-CCF 1102 can configure some triggers about billing policies and information in the underlying network. Upon receiving an occurrence notification from the underlying network 1106, the SD-CCF 1102 can perform a sequence of actions, such as configuring a service layer billing policy, notifying other billing-related entities (e.g., CTF and billing SC) to update billing operations.

[0084] Performing service layer charging association can update the service layer charging policy and adjust the charging operation and service layer CDR. Specifically, SD-CCF follows the workflow by performing multiple actions as a response to triggers received from the underlying network, such as if it needs to change the service layer charging policy, if it needs to capture some new type of chargeable event, etc.

[0085] like Fig.11 As shown, the service domain charging correlation function (SD-CCF) 1102 can be hosted within the M2M service layer instance 1104, for example, as a separate service capability within the M2M service layer instance 1104 (eg, Fig.11 SD-CCF 1102 may also be a sub-function within an existing billing SC.

[0086] Service layer charging association is defined as the process of adjusting the service layer charging behavior based on the charging association information provided by the underlying network. An example of charging association can be as follows: the service subscriber depletes credits in the underlying network 1106 when receiving service data through the service layer platform. The service provider gets notified from the underlying network 1106 and starts charging additional charges from the service subscriber's service layer credit account to maintain the same QoS for data retrieval.

[0087] Service layer charging association rules may define rules for performing service layer charging association. Charging association rules may be service specific and managed by the service provider in a preconfigured manner or dynamically. Rules may include the following: enablement indication, association schedule, network charging association trigger set, and type of underlying network.

[0088] The enable indication may indicate whether charging association is enabled for the service, i.e., whether the service is allowed to associate charging policies, charging information, or both. Note that the association rules should be service-specific, i.e., rules per service. In other words, different services may have different charging association rules.

[0089] The association schedule may indicate how often charging association is performed.

[0090] The network charging correlation trigger set may indicate a set of triggers from the underlying network that may trigger a service layer charging correlation operation.

[0091] The type of underlying network may indicate what type of underlying network is expected to be included in the charging association.

[0092] A network charging correlation trigger may define a triggering event occurring in the underlying network that triggers a charging correlation operation at the service layer 1104. The charging correlation trigger may then be further divided into two types:

[0093] The charging policy trigger may refer to a charging policy change in the underlying network 1106 that may require the service layer 1104 to change the service layer charging policy. The underlying network changes its charging policy for the transmission service data flow, and the service layer may also need to adjust the charging policy accordingly. The charging policy trigger may be (but is not limited to) the following: QoS parameter change, charging rate change, charging measurement parameter change, service subscriber's underlying network subscription change, and underlying network charging discount or allowance change.

[0094] The QoS parameter change trigger may mean that the QoS parameters bound to the underlying network charging policy are changed for the transmission service data flow. Therefore, the service layer 1104 needs to update the charging policy. For example, the 3GPP network operator changes the guaranteed data rate from 10Mbps to 5Mbps using the same charging rate for the transmission service data flow. According to the launch data connectivity model, the service provider bears the cost of the 3GPP network data and charges the service subscriber. The service provider can use the same charging rate to reduce the data rate bound to the service layer charging policy, or apply a higher charging rate that maintains the original data rate.

[0095] A charging rate change trigger may mean that the charging rate changes in the underlying network, thereby affecting the service layer charging rate.

[0096] The charging measurement parameter change trigger may mean that the charging measurement method is changed for the service layer data flow in the underlying network. For example, since the M2M application 1108 can deploy a large number of devices, the charging measurement is changed from data volume-based charging to transaction-based charging for the sensor data retrieval service, and each transaction requires a small amount of data.

[0097] When a service subscriber changes his monthly data plan in the underlying network, a service subscriber triggers an underlying network subscription change, which may enable the user to obtain more bandwidth (eg, higher data rates) to use services at the service layer.

[0098] A change in the underlying network billing discount or allowance trigger may enable the service layer 1104 to change the service layer policy or apply another policy to the service subscriber with a discounted rate for delaying / scheduling its traffic so that it occurs during a specified event.

[0099] The charging event trigger may include an event that triggers the service layer to update the service layer charging information record (e.g., CDR) or update the charging operation. For a service, using different events from the underlying network, the service layer can dynamically apply different charging policies and collect different chargeable events. For example, the trigger may be (but not limited to) the following: reaching the threshold of the amount of data sent, service start / stop, credit exhaustion, service data flow unloading, and the availability of discounted bandwidth in the underlying network.

[0100] The reaching of an outgoing data volume threshold trigger may indicate to the service subscriber that a data volume threshold for an outgoing data link in the underlying network has been reached, which may typically result in additional billing of the service subscriber for future data transmissions.

[0101] A service start / stop trigger can instruct a service data flow to start / stop transmission over a specified underlying network.

[0102] The credit exhaustion trigger may indicate that the subscriber's credit in the underlying network may not be sufficient to continue using the service with the current QoS. This may trigger the service layer to 1) stop providing the service or reduce the QoS level; 2) maintain the same QoS by charging the subscriber more at the service layer. In other words, option 1 applies a new charging policy with different QoS parameters; while option 2 applies a new charging policy with a higher charging rate. As an example, this information may be represented and exchanged through a specific action attribute value pair (AVP) and a final unit action AVP defined by 3GPP.

[0103] For the service data flow offloading trigger, the underlying network 1106 instructs it to offload the service data flow of the service to another underlying network, so that the service layer 1104 can adjust the charging operation for the new underlying network. There are many reasons that can trigger offloading, such as congestion in the original underlying network, and better transmission quality due to mobility.

[0104] The availability of discounted bandwidth in the underlying network triggers can enable service subscribers to receive higher quality of service at the service layer while being billed at a discount.Depending on the scenario, the service layer can adjust the policies applied to the service subscribers.

[0105] A rule can be equivalent to a policy, and a trigger can be a special type of event that requires additional actions when the event occurs. To avoid confusion, the term "billing correlation rule" is used to distinguish it from the traditional concept of "billing policy"; the term "billing correlation trigger" is used to distinguish it from the concept of "billable event".

[0106] SD-CCF 1102 may be responsible for creating, updating, and deleting charging association rules for services. Charging association rules may be pre-configured for services or dynamically updated through communication between SD-CCF 1102 and service layer charging entities. Fig.12 is a flow chart illustrating a process for creating a new charging association rule in one embodiment.

[0107] Fig.12 Step 1 of 1202 indicates that the charging service capability 1202 first issues a request (CREATE) to the SD-CCF 1102 to create a new charging association rule. For example, there are multiple events that can trigger the request issued by the charging SC 1202.

[0108] A new service is added to the service platform, and the service provider wants to create a charging association rule for the new service.

[0109] A new version of an existing service is provided with new features that require more charging-related operations using the underlying network. In this case, since the existing rules will apply to the old version, the service provider wishes to create new rules rather than update the existing rules.

[0110] The underlying network 1106 shares its charging capability information with the service layer 1104, for example, what events or triggers the underlying network can / is allowed to send to the service layer. Based on this information, the service layer can create / update charging association rules accordingly.

[0111] In the request message, the charging SC 1202 will specify details about the new rule, such as what type of underlying network 1106 should be associated, what triggers are enabled for charging association, and the service to create the new rule. The SD-CCF 1102 will create the charging association rule on the request. An exemplary non-limiting charging association rule is shown in Table 2 related to the home supervision service.

[0112] Table 2: Example of billing association rules for home monitoring services

[0113]

[0114] The Charging SC 1202 refers to the entity responsible for charging at the service layer, e.g. Figure 6 SD-CS 610. In addition, the requester does not need to be a service capability entity. The requester can be any entity that defines charging association rules, even an underlying network entity. For example, the requester can be an application, in which case the application defines the service.

[0115] In the event that the SD-CCF 1102 contacts the Billing SC 1202 to obtain more details or missing information in the request to create a new association rule, Fig.12 Step 2 is an optional step.

[0116] exist Fig.12 In step 3, after creating the new rule, the SD-CCF 1102 returns the reachable address or interface to the charging SC 1202, so that the charging SC 1202 can access the charging association rule in the future.

[0117] Charging correlation triggers from the underlying network 1106 may also require the SD-CCF 1102 to create a new service layer charging policy, which will be discussed in the next section.

[0118] A similar process may be applied to update or delete existing charging association rules by replacing CREATE in the request.

[0119] Some exemplary message exchange processes between the service layer and the underlying network are defined below for charging association. The SD-CCF 1102 is shown as part of the charging SC 1202 for illustration in this subsection. Alternatively, the SD-CCF 1102 can be a stand-alone function, or the SD-CCF 1102 can be added as part of another SC in the service layer.

[0120] To understand, execution Fig.12 The entities of the steps illustrated in the figure are logical entities and can be stored in a device, server or other computer system (such as in Fig. 22C or Fig.22D The logical entity may be implemented in the form of software (i.e., computer executable instructions) stored in a memory of a computing device (e.g., one of the computer systems illustrated in FIG. 1 ) and executed on a processor of the device, server, or other computer system. That is, the logical entity may be implemented in the form of software (i.e., computer executable instructions) stored in a computing device (e.g., one of the computer systems illustrated in FIG. 1 ). Fig. 22C or Fig.22D The present invention is implemented in the form of software (i.e., computer executable instructions) in the memory of the device or computer system shown in FIG. Fig.12 The method(s) illustrated in the figure, the computer executable instructions when executed by the processor of the computing device perform Fig.12 It should also be understood that the steps illustrated in FIG. 1 can be performed by the communication circuit system of the node under the control of the processor of the node and the computer executable instructions (e.g., software) executed by the processor. Fig.12 Any sending and receiving steps illustrated in .

[0121] Fig.13 is a flow chart illustrating a message exchange process for charging policy association according to one embodiment.

[0122] exist Fig.13 In step 0, before configuring the charging policy triggers in the underlying network, the SD-CCF 1102 may interact with the CTF 1302 to obtain the charging policy triggers that may be configured in the underlying network 1106. These triggers may affect the service layer charging behavior.

[0123] This can be done in an on-demand manner. Specifically, CTF 1302 examines the expected chargeable events and the information included in these events, and determines whether there are any such triggers. If there are any pieces of information that can be affected by the charging policy update, CTF 1302 will contact SD-CCF 1102 to specify the charging policy triggers required for the charging association. In the message, the following information may be included: service information, charging policy ID and chargeable event ID, and charging attribute information.

[0124] With respect to the service information, the SD-CCF 1102 may understand what service the charging association trigger is applicable to.

[0125] For the charging policy ID and the chargeable event ID, the SD-CCF 1102 may use this information to retrieve more detailed charging policy and chargeable event information to find out what charging association triggers need to be configured.

[0126] For billing attribute information, such as data rate or billing measurement method, SD-CCF1102 can use this information to understand the type of trigger to be configured.

[0127] Therefore, the SD-CCF 1102 does not need to contact all CTFs one by one, and the SD-CCF 1102 configures the charging policy trigger only when the CTF initiates the interaction with the specified charging policy trigger.

[0128] exist Fig.13 In step 1, SD-CCF 1102 configures some charging policy triggers in the underlying network. These triggers occurring in the underlying network may affect the service layer charging policy. In the configuration message, SD-CCF 1102 may specify a list of policy triggers. The service layer maintains configuration information per service for each trigger, i.e., the service layer records which service requires which trigger.

[0129] Since the underlying network may not know what the service is, the message sent to the underlying network 1106 only contains the trigger information. In addition, the service layer 1104 can also configure triggers for individual service subscribers or a group of service subscribers. In other words, the underlying network only notifies the service layer 1104 when the configured trigger is generated for the specified subscriber. This reduces the communication overhead between the service layer 1104 and the underlying network 1106.

[0130] The SD-CCF 1102 may aggregate multiple configurations regarding different policy triggers, each of the multiple configurations corresponding to a different service.

[0131] There may be multiple services that configure the same trigger. As an example, the SD-CCF 1102 may create and maintain charging association rules for the home supervision service. The rule may indicate whether charging association is enabled for the service, what set of triggers are configured for the service, and what charging policies and chargeable events will be affected by the trigger. Note that the trigger / charging policy / chargeable event may be identified by its ID.

[0132] As an example, the service layer 1104 may know the address of the underlying network entity via pre-provisioning.

[0133] exist Fig.13 In step 2, once the underlying network entity (e.g., PCRF / PCEF in 3GPP network, policy enforcement point (PEP) in BBF fixed network) detects the occurrence of subscription trigger, the underlying network entity sends a notification to SD-CCF 1102 indicating what trigger occurred. In addition, the underlying network should specify the necessary parameters that have changed. For example, the threshold of the amount of new data initiated, the new data rate bound to the existing charging policy. The service layer 1104 needs these parameters to create / update the service layer charging policy accordingly.

[0134] exist Fig.13 In step 3 of , since there may be multiple services configured with the same trigger, upon receiving the notification from the underlying network, the SD-CCF 1102 may check what service configures the charging policy trigger (e.g., compare the trigger ID and service ID with the maintenance information of what service configures what trigger). Verify whether the reported trigger is enabled for the specific service. Also, check the information about what charging policy and chargeable events will be affected by the reported trigger.

[0135] Then, SD-CCF 1102 updates the charging policy based on the parameters included in the notification. Specifically, SD-CCF 1102 may perform one of the following actions: create a new charging policy or update (multiple) attributes in an existing charging policy.

[0136] Creating a new charging policy means that the underlying network 1106 changes its charging policy, and the service layer does not have an existing charging policy corresponding to the change. For example, the underlying network 1106 changes the charging measurement for air quality sensor data readings from volume-based charging to transaction-based charging, and the service layer 1104 needs to establish a transaction-based charging policy for the sensor data reading service and maintain the previous data volume-based policy that can be used by other types of underlying networks 1106.

[0137] Updating the attribute(s) in the existing charging policy means that the charging policy change in the underlying network affects the existing service layer charging policy, and the service layer 1104 needs to change some attributes in the policy, such as the data volume threshold and the charging rate.

[0138] Fig.13 Step 4 is an optional step 1102 that may be needed to update an existing service layer CDR when the SD-CCF receives a specific type of trigger from the underlying network. For example, the underlying network increases the billing rate of the service data flow, and the SD-CCF 1102 can update the billing rate at the service layer billing data recorder (CDR). Another example, the underlying network 1106 decides to apply a discount rate to all data during a period of time, so the service provider can also apply a lower service layer billing price during that period.

[0139] Note that the CDR can be saved in a database, where the SD-CCF 1102, CTF, and billing SC 1202 can access and process the CDR for different reasons. The SD-CCF 1102 updates the CDR due to the association operation; the CTF updates the CDR because the CTF captures some new billable events; the billing SC 1202 updates / processes the CDR because the billing SC 1202 may need to pass the CDR file to the billing system.

[0140] exist Fig.13 In step 5, SD-CCF 1102 notifies the charging trigger function (CTF) 1302 in other service capabilities to change the charging behavior according to the new charging policy. In the notification, SD-CCF 1102 indicates the chargeable events that the CTF 1302 specified by the event ID needs to collect.

[0141] Then, the CTF 1302 looks up the event ID to understand what information should be included for the chargeable event. For example, the underlying network changes the charging measurement method from transaction-based to data volume-based for the data retrieval service, so the SD-CCF 1102 notifies the CTF 1302 in the session management SC to start collecting the data volume of the service data flow for the data retrieval service.

[0142] Note that during the registration process, the SD-CCF 102 may be aware of the existence of those CTFs 1302. For example, in oneM2M, there are <csebase> 、 <remotecse>,and <ae>resources, the SD-CCF can know which CTF 1302 to contact by checking these resources.

[0143] Fig.13 Step 6 is an optional step. CTF 1302 may send a confirmation to SD-CCF 1102 to confirm the change in charging behavior.

[0144] Note that in addition to relying entirely on the underlying network 1106, the client (e.g., application) itself can also receive some automatic messages (e.g., data usage reminders) from the underlying network. Therefore, the client can actively report this information to the SD-CCF 1102 to perform the association. In this case, the underlying network must first notify the client, and then the client uses the charging policy trigger to notify the SD-CCF 1102. The charging event trigger has a similar situation to this scenario.

[0145] To understand, execution Fig.13 The entities of the steps illustrated in the figure are logical entities and can be stored in a device, server or other computer system (such as in Fig. 22C or Fig.22D The logical entity may be implemented in the form of software (i.e., computer executable instructions) stored in a memory of a computing device (e.g., one of the computer systems illustrated in FIG. 1 ) and executed on a processor of the device, server, or other computer system. That is, the logical entity may be implemented in the form of software (i.e., computer executable instructions) stored in a computing device (e.g., one of the computer systems illustrated in FIG. 1 ). Fig. 22C or Fig.22D The present invention is implemented in the form of software (i.e., computer executable instructions) in the memory of the device or computer system shown in FIG. Fig.13 The method(s) illustrated in the figure, the computer executable instructions when executed by the processor of the computing device perform Fig.13 It should also be understood that the steps illustrated in FIG. 1 can be performed by the communication circuit system of the node under the control of the processor of the node and the computer executable instructions (e.g., software) executed by the processor. Fig.13 Any sending and receiving steps illustrated in .

[0146] Fig.14 is a flow chart illustrating a message exchange process for facilitating charging information correlation.

[0147] exist Fig.14 In step 1 of , SD-CCF 1102 first configures some charging event triggers in the underlying network. Similar to charging policy triggers, these triggers refer to some events that can affect the charging behavior of the service layer. Similar to the charging policy association scenario, CTF 1302 contacts SD-CCF 1102 on an on-demand basis regarding the desired charging association triggers so that SD-CCF 1102 can configure the triggers in the underlying network. Fig.13 Further details are discussed in the description of step 0 shown.

[0148] Fig.14 Step 2 and Fig.13 The procedure is similar to step 2.

[0149] exist Fig.14 In step 3 of , SD-CCF 1102 records the charging information trigger and determines other actions based on the type of trigger and the service for which the trigger is configured (e.g., applying a new charging rate for the service, starting to collect data volume information). SD-CCF 1102 may also verify whether the reported trigger is enabled for a particular service and check information about what charging policies and chargeable events the reported trigger will affect.

[0150] exist Fig.14 In step 4 of the present invention, the SD-CCF 1102 notifies the CTF 1302 in other SCs of the new charging action determined based on the trigger. The SD-CCF 1102 can know the existence of these CTFs 1302 by checking the result of the registration process. For example, the SD-CCF 1102 notifies the CTF 1302 in the session management SC to start collecting data volume for a service subscriber who subscribes to the home supervision service and reaches a data volume threshold.

[0151] exist Fig.14 In step 5 of , upon receiving the configuration from SD-CCF 1102, charging trigger function (CTF) 1302 updates the list of chargeable events per service. Specifically, CTF 1302 maintains some information about what chargeable events are expected to be collected for what service and what information should be included for each chargeable event. If some new type of chargeable event needs to be collected, CTF 1302 can check the event information according to the event ID that identifies the event and add the new event to the list.

[0152] exist Fig.14 In step 6 of , as an optional step, CTF 1302 may send a confirmation to SD-CCF 1102 to confirm the change in charging behavior.

[0153] In some cases, the underlying network 1106 may also initiate the charging association process by communicating with the service layer 1104. For example, the underlying network 1106 (e.g., 3GPP network) decides to offload the service data flow to another type of underlying network 1106 (e.g., WiFi) for some reason (e.g., network congestion, better communication quality). In this case, in the absence of a configuration step (i.e., in Fig.14 In the case of step 1) in , the underlying network 1106 directly reports the occurrence of the trigger to the SD-CCF.

[0154] To understand, execution Fig.14 The entities of the steps illustrated in the figure are logical entities and can be stored in a node, device, server or other computer system (such as Fig. 22C or Fig.22D The logical entity may be implemented in the form of software (i.e., computer executable instructions) in a memory of a node, device, server, or other computer system (e.g., one of the computer systems illustrated in FIG. 1 ) and executed on a processor of the node, device, server, or other computer system. That is, the logical entity may be implemented in the form of software (i.e., computer executable instructions) stored in a computing device (e.g., in Fig. 22C or Fig.22D The present invention is implemented in the form of software (i.e., computer executable instructions) in the memory of the device or computer system shown in FIG. Fig.14 The method(s) illustrated in the figure, the computer executable instructions when executed by the processor of the computing device perform Fig.14 It should also be understood that the steps illustrated in FIG. 1 can be performed by the communication circuit system of the node under the control of the processor of the node and the computer executable instructions (e.g., software) executed by the processor. Fig.14 Any sending and receiving steps illustrated in .

[0155] Fig.15 is a flow chart illustrating an exemplary method for performing service layer charging correlation.The correlation operation can be applied to both charging policy triggers and charging event triggers captured by the underlying network.

[0156] exist Fig.15 In step 1 of , the charging association method is triggered when the SD-CCF 1102 receives a notification indicating that a configured trigger has occurred in the underlying network 1106. The notification specifies a trigger ID and the underlying network ID that generated the notification. The SD-CCF 1102 can use the trigger ID to retrieve associated trigger information, such as whether the trigger is policy-related or charging information-related, and what event occurred in the underlying network.

[0157] exist Fig.15 In step 2, SD-CCF 1102 checks the charging association rules to determine whether charging association with respect to the reported trigger is enabled / allowed, i.e., whether the reported trigger was previously configured by SD-CCF 1102. Since the underlying network may initiate the trigger report in some cases, the service layer needs to verify for which service the reported trigger is enabled.

[0158] Since the underlying network may not specify service information and multiple services may configure the same trigger, the SD-CCF 1102 also verifies which services configure the reported trigger.

[0159] Specifically, the SD-CCF 1102 needs to find out things such as what service is subscribed to the trigger, and whether the charging association operation is enabled for the service. If the check returns no, then there is no charging association operation that has been performed. This step can be performed by checking the information created and maintained by the SD-CCF 1102. For example, the SD-CCF 1102 will maintain information about what triggers it has configured for which service(s) at the underlying network, and whether the association trigger is enabled or allowed for the service. The embodiment section will specify the structure of this information about association rules and triggers for oneM2M.

[0160] exist Fig.15 In step 3, based on Fig.15 In the action in step 2, if the trigger for billing management and reporting is enabled for the service, the SD-CCF 1102 continues to check whether the trigger is related to the billing policy or billing information, so that different operations are performed for the two types of triggers.

[0161] If charging correlation is not allowed, the SD-CCF 1102 checks the trigger information and lets the service provider determine whether to add the reported trigger to the correlation rule for the service. If the trigger is not understandable, the SD-CCF 1102 will require information of the reported trigger.

[0162] Executed for billing policy triggers Fig.15 Follow steps 4 to 10.

[0163] exist Fig.15 In step 4, when the trigger is related to the charging policy, SD-CCF 1102 first updates the service layer charging policy corresponding to the trigger from the underlying network. Specifically, in the existing charging policy, SD-CCF 1102 can create a new charging policy or update (multiple) attributes.

[0164] exist Fig.15 In step 5, SD-CCF 1102 further checks whether it is necessary to notify CTF 1302 in other SCs about the updated charging policy, so that CTF 1302 can adjust the way of collecting chargeable events. For example, changing the charging policy from a transaction-based charging policy to a data volume-based charging policy requires CTF 1302 to insert data volume information into the collected charging records, and it is likely that some new chargeable events that are not required for transaction-based charging will be collected.

[0165] In some cases, since charging policy changes only affect CDR processing, there is no need to communicate with the CTF 1302. For example, changing the charging rate will not require the CTF to change any behavior to collect chargeable events and the information in the collected charging records.

[0166] To make this decision, the SD-CCF 1102 may check the information maintained at the service layer to find out whether it is necessary to contact the CTF 1302 and which CTF 1302 needs to be notified at which entity (if necessary). For example, such information may be (but is not limited to) the following:

[0167] o A CTF 1302 defined in oneM2M to indicate what functionality (e.g., session management) comprises <csebase> 、 <remotecse>,and <ae>resource.

[0168] ο Resources defined in oneM2M for service-level charging policies for included services <statscollect>If the charging policy is affected, ie the reported trigger changes some attributes in the charging policy service, the CTF 1302 needs to be notified.

[0169] ο Resources defined in oneM2M for service-layer billable events for included services <eventconfig>Similar to the charging policy, the SD-CCF 1102 looks at the resource to determine if the CTF 1302 needs to be notified based on the trigger received from the underlying network.

[0170] exist Fig.15 In step 6, SD-CCF 1102 notifies the charging SC 1202 and CTF 1302 in the relevant SC of the change in charging policy and the expected chargeable events. The message includes the new charging policy, the expected chargeable events, and the service ID. The charging SC 1202 and CTF 1302 can use this information to adjust the way to collect chargeable events and the information collected for chargeable events.

[0171] exist Fig.15 In step 7, SD-CCF 1102 checks whether it needs to notify a specific SC to change the service provision parameters. For example, to change the maximum data rate bound to the underlying network charging policy for a data retrieval service; SD-CCF 1102 needs to notify the session management SC to adjust the maximum data rate accordingly.

[0172] exist Fig.15 In step 8, SD-CCF 1102 notifies the relevant SC of the change of the service provision parameter. Specifically, SD-CCF 1102 indicates the parameter to be changed and the new value.

[0173] exist Fig.15 In step 9, SD-CCF 1102 further checks whether it is necessary to reprocess the existing CDR for the service with the updated charging policy. For example, the underlying network applies transaction-based charging to the service data flow of the sensor data reading service that was previously based on data volume, so that the service layer needs to remove the data volume value from the existing CDR.

[0174] exist Fig.15 In step 10, SD-CCF 1102 notifies charging SC 1202 to update the existing service layer CDR. The notification includes specific instructions on how to update the CDR (e.g., remove data volume information, update charging rate). In one embodiment, how to update the CDR is the responsibility of charging SC 1202 and is not performed by SD-CCF 1102.

[0175] Executed for billing event triggers Fig.15 Step 11 to Step 14.

[0176] exist Fig.15 In step 11 of , upon receiving a charging event trigger, the SD-CCF 1102 determines whether it is necessary to apply another charging policy corresponding to the trigger that occurred in the underlying network. Note that a charging information trigger will not require any update to the service layer charging policy, but may require another policy to be applied to the service. For example, a trigger of reaching a data volume threshold requires the service layer to start charging the service subscriber additional fees for future data volumes.

[0177] Fig.15 Step 12 and Fig.15 The SD-CCF 1102 notifies the charging SC 1202 and the CTF 1302 in the relevant SC of the change in the charging policy applied.

[0178] Fig.15 Steps 13-14 and Fig.15 Steps 7 and 8 are similar. SD-CCF 1102 checks whether a specific SC needs to be notified of a change in service provision parameters and notifies the relevant SC of the change in service provision parameters (if necessary).

[0179] Note that it is also possible that the service layer 1104 provides some information to the underlying network 1106 so that the underlying network 1106 can adjust the charging behavior per user or per service. For example, a service subscriber updates its service layer subscription to a premium account, which gives the service subscriber unlimited free data to access services in the 3GPP network. The service layer 1104 needs to inform the 3GPP network that it will not count the data volume of the user's service in its 3GPP network monthly data plan.

[0180] To understand, execution Fig.15 The entities of the steps illustrated in the figure are logical entities and can be stored in a node, device, server or other computer system (such as Fig. 22C or Fig.22D The logical entity may be implemented in the form of software (i.e., computer executable instructions) in a memory of a node, device, server, or other computer system (e.g., one of the computer systems illustrated in FIG. 1 ) and executed on a processor of the node, device, server, or other computer system. That is, the logical entity may be implemented in the form of software (i.e., computer executable instructions) stored in a computing device (e.g., in Fig. 22C or Fig.22D The present invention is implemented in the form of software (i.e., computer executable instructions) in the memory of the device or computer system shown in FIG. Fig.15 The method(s) illustrated in the figure, the computer executable instructions when executed by the processor of the computing device perform Fig.15 It should also be understood that the steps illustrated in FIG. 1 can be performed by the communication circuit system of the node under the control of the processor of the node and the computer executable instructions (e.g., software) executed by the processor. Fig.15 Any sending and receiving steps illustrated in .

[0181] Fig.16 is a diagram illustrating an exemplary embodiment for implementing the proposed SD-CCF 1102 as a part of the Service Charging & Settlement (SCA) CSF 1604 based on the oneM2M functional architecture 1600. Note that the proposed SD-CCF can also be added as a sub-function of the Network Service Exposure, Service Execution and Triggering (NSSE) CSF 1606, which is mainly responsible for managing the communication with the underlying network to access the network service function through the Mcn reference point.

[0182] This section discloses the oneM2M resource structure enhancements to support the charging correlation function of the SCA CSF 1604.

[0183] Note that the following is a graphical representation of the oneM2M definition used to describe the resource structure: Boxes are used for resources and sub-resources. Boxes with rounded corners are used for attributes.

[0184] Fig.17 It is a diagram that reflects the service layer billing association rules <chargingcorrelationrule>Schematic diagram of resource 1702, which is described in Table 3. There may be multiple charging association rules for different services, that is, the charging association rules are service-specific identified by the rule ID 1704 and service ID 1714 attributes. <chargingcorrelationrule>Resource 1702 added as <csebase> 、 <remotecse>,and <ae>The subresources of a resource.

[0185] Table 3: <chargingcorrelationrule>Resource properties

[0186]

[0187]

[0188] Fig.18 is a diagram showing service-level charging association rules reflected for services <chargingcorrelationtrigger>A schematic diagram of resource 1802 is described in Table 4.

[0189] Table 4: <chargingcorrelationtrigger>Resource properties

[0190]

[0191] In order to present more details about how the SD-CCF 1102 works with the underlying network 1106 for charging association, the 3GPP network is used as an example for explanation.

[0192] Fig.19 is a schematic diagram illustrating an exemplary embodiment of oneM2M charging policy association with a 3GPP network, which demonstrates how the proposed oneM2M SD-CCF 1102 works to associate charging policy changes in the 3GPP network. In this case, the threshold of the amount of data sent in the 3GPP network is changed, and the 3GPP network notifies the oneM2M service layer. Therefore, the oneM2M service layer platform updates the service layer charging policy and notifies the SD-CTF 1902 to apply the new charging policy.

[0193] exist Fig.19 In step 1, SD-CCF 1102 checks <chargingcorrelationrule>Resources are used to determine that a charging policy trigger that initiates a change in the data volume threshold is enabled for the service. This step can be triggered by receiving some charging policy triggers from the CTF. Specifically, the SD-CTF 1902 can find the charging policy trigger by checking the billable events to be collected and the information therein, and then send a notification to the SD-CCF 1102. For example, the SD-CTF 1902 finds that the data rate information is expected to collect the billable events indicating the start of the data transmission (service layer session management function) of the sensor data reading. SD-CTF1902 will ask SD-CCF 1102 to configure the charging policy trigger in the underlying 3GPP network so that any changes in the data rate of the service data flow in the 3GPP network will be reported to the service layer 1104.

[0194] exist Fig.19 In step 2, SD-CCF 1102 sends a subscription message to PCRF 1908 in 3GPP network 1906 through Mcn / Rx reference point. The message includes a trigger ID and an underlying network ID of the device (e.g., an external ID to 3GPP network 1906 for indicating a service platform subscribing to the trigger).

[0195] exist Fig.19 In step 3, if the 3GPP network 1906 changes the threshold for the amount of data to be sent, the PCRF 1908 sends a notification to the SD-CCF 1102 via the Mcn reference point, including: trigger ID, trigger subscription ID, and occurrence timestamp. In this example, since the threshold for the amount of data to be sent has changed, the 3GPP network 1906 sends a new data amount threshold (e.g., a granted service unit attribute value pair (AVP)) assuming that the diameter protocol is used across the 3GPP network 1906 and the oneM2M service layer platform 1904.

[0196] exist Fig.19 In step 4 of , upon receiving the trigger notification from the 3GPP network 1906, the oneM2M service layer 1904 <chargingcorrelationtrigger>The oneM2M service layer 1904 may update the charging policy by using the relevant charging policy ID attribute in the resource. For example, the oneM2M service layer 1904 may change the data rate bound to the charging policy for the data retrieval service, or may change the data volume threshold for the home monitoring service. More specifically, the oneM2M resource <statscollect>and <eventconfig>Changes are made, which are designed to maintain billing policies and billable event information respectively.

[0197] exist Fig.19 In step 5, SD-CCF 1902 then notifies SD-CTF 1902 in other CSFs of the change in charging policy, i.e., starts charging additional fees to service subscribers according to the new threshold. Specifically, the notification includes the service ID, the newly applied charging policy ID, and the related chargeable event ID.

[0198] exist Fig.19 In step 6, SD-CTF 1902 will access the resource <statscollect>and <eventconfig>To get more details of billing records collected by billing policy ID and event ID.

[0199] exist Fig.19 In step 7, as an optional step, SD-CTF 1902 may send a confirmation to SD-CCF 1102 to confirm the change in the charging behavior.

[0200] To understand, execution Fig.19 The entities of the steps illustrated in the figure are logical entities and can be stored in a device, server or other computer system (such as in Fig. 22C or Fig.22D The logical entity may be implemented in the form of software (i.e., computer executable instructions) stored in a memory of a computing device (e.g., one of the computer systems illustrated in FIG. 1 ) and executed on a processor of the device, server, or other computer system. That is, the logical entity may be implemented in the form of software (i.e., computer executable instructions) stored in a computing device (e.g., one of the computer systems illustrated in FIG. 1 ). Fig. 22C or Fig.22D The present invention is implemented in the form of software (i.e., computer executable instructions) in the memory of the device or computer system shown in FIG. Fig.19 The method(s) illustrated in the figure, the computer executable instructions when executed by the processor of the computing device perform Fig.19 It should also be understood that the steps illustrated in FIG. 1 can be performed by the communication circuit system of the node under the control of the processor of the node and the computer executable instructions (e.g., software) executed by the processor. Fig.19 Any sending and receiving steps illustrated in .

[0201] Fig. 20 is a schematic diagram illustrating an exemplary embodiment of oneM2M charging information association with a 3GPP network use case, which demonstrates how the proposed oneM2M SD-CCF 1102 works to associate charging information provided by the 3GPP network 1906. Specifically, a threshold of the amount of data sent is reached in the 3GPP network. Therefore, the SD-CCF 1102 decides to apply a new charging rate to future service data flows, and notifies the SD-CTF 1902 to include the amount of data when collecting chargeable events for the service.

[0202] Fig. 20 Step 1 and Fig.19 Similar to step 1. SD-CCF 1102 Check <chargingcorrelationrule>Resources to ensure that the charging information trigger that reaches the threshold of the amount of data to be sent is enabled for the service. In addition, the SD-CCF 1102 will initiate this step by receiving some information from the CTF. Fig.19 More details can be found in the description of step 1 of . The only difference is that CTF reports the billing event trigger instead of Fig.19 The billing policy trigger of step 1.

[0203] Fig. 20 Step 2 and Fig.19 SD-CCF 1102 sends a subscription message to PCRF 1908 in the 3GPP network via the Mcn reference point. The message includes a trigger ID and a service provider ID (an external ID to the 3GPP network for indicating the service platform that subscribes to the trigger). PCRF 1908 then notifies PCEF 2002 to subscribe to the trigger via the Event Trigger AVP.

[0204] exist Fig. 20 In step 3, once PCEF 2002 finds that the threshold has been reached, it reports the event of reaching the data volume threshold through the service unit AVP used to indicate the use of the measurement amount. In this step, PCEF 2002 first reports to PCRF 1908, and PCRF 1908 sends an event notification to SD-CCF 1102 through the Mcn / Rx reference point.

[0205] exist Fig. 20 In step 4 of , SD-CCF 1102 decides to apply a new charging rate for the additional data volume and decides to require SD-CTF 1902 to include the data volume in the charging record. This can be done by updating the resource <statscollect>and <eventconfig>The billing strategy and billable events are used.

[0206] Fig. 20 Steps 5 to 7 of Fig.19 The steps 5-7 are similar.

[0207] To understand, execution Fig. 20 The entities of the steps illustrated in the figure are logical entities and can be stored in a device, server or other computer system (such as in Fig. 22C or Fig.22D The logical entities may be implemented in the form of software (i.e., computer executable instructions) stored in a memory of a computing device (e.g., one of the computer systems illustrated in FIG. 1 ) and executed on a processor of a device, server, or other computer system. That is, the logical entities may be implemented in the form of software (i.e., computer executable instructions) stored in a computing device (e.g., one of the computer systems illustrated in FIG. 1 ). Fig. 22C or Fig.22D The present invention is implemented in the form of software (e.g., computer executable instructions) in the memory of the device or computer system shown in FIG. Fig. 20 The method(s) illustrated in the figure, the computer executable instructions when executed by the processor of the computing device perform Fig. 20 It should also be understood that the steps illustrated in FIG. 1 can be performed by the communication circuit system of the node under the control of the processor of the node and the computer executable instructions (ie, software) executed by the processor. Fig. 20 Any sending and receiving steps illustrated in .

[0208] As mentioned above, oneM2M is defining the capabilities supported by the oneM2M service layer. These capabilities are called Capability Service Functions (CSFs). The oneM2M service layer is called Capability Service Entity (CSE).

[0209] Fig.21 2 is a schematic diagram illustrating an embodiment of the proposed SD-CCF 1102 in the oneM2M SoA architecture 2100, wherein the SD-CCF 1102 is inserted as a part of the settlement (ACC) service component 2102. Other service components may communicate with the SD-CCF 1102 regarding charging related issues via the Msc reference point. As another embodiment, the SD-CCF 1102 may be a part of the service disclosure component 2104, wherein the SD-CCF 1102 is considered as a public function of other service components and applications.

[0210] An interface, such as a graphical user interface (GUI), may be used to help a user control and / or configure functions associated with service layer billing. The interface may be at a device, gateway, or server. The user interface may display when it is triggered to generate billable time, and the information elements included in the billing record. In addition, API operations, such as messages exchanged between the M2M server and the underlying network server, may also be displayed.

[0211] Fig.23A is a schematic diagram illustrating an interface 2302 that allows a user to set billing association rules and triggers and view billing association rules and triggers. Fig. 23B 2304 is a schematic diagram illustrating an interface 2304 that can be used by a consumer at a user device. In this example, the interface 2304 displays the remaining bandwidth for the initiation flow. It is understood that a display (such as described below) can be used to FIG. 22C to FIG. 22D ) to generate interfaces 2302 and 2304.

[0212] Example M2M / IoT / WoT communication system

[0213] Fig.22A is a schematic diagram of an example machine-to-machine (M2M), Internet of Things (IoT), or Internet of Everything (WoT) communication system 10 in which one or more disclosed embodiments may be implemented. In general, M2M technology provides a building block for IoT / WoT, and any M2M device, M2M gateway, MEM server, or M2M service platform may be a component or node of IoT / WoT and an IoT / WoT service layer, etc. The communication system 10 may be used to implement the functionality of the disclosed embodiments and may include functional and logical entities such as PCRF 702, 914 and 1908, MTC-IWF 704, PCEF 706, 912 and 2002, charging entity 916, 3GPP CN 910, SD-CS 602, SD-ODS 608, SD-OFCS 606, SD-CTF 610, 1302 and 1902, SD-CCF 1102, M2M application 1108, charging SC 1202, service charging and settlement CSF 1604, network service exposure CSF 1606, 3GPPCN 1906, service layer 904, 1600, 1904, ACC 2104, service exposure component 2104, logic at UE 906, and logic for generating interfaces such as interfaces 2302 and 2304.

[0214] As in Fig.22A As shown in FIG. 1 , the M2M / IoT / WoT communication system 10 includes a communication network 12. The communication network 12 may be a fixed network (e.g., Ethernet, optical fiber, ISDN, PLC, etc.) or a wireless network (e.g., WLAN, cellular, etc.) or a network of heterogeneous networks. For example, the communication network 12 may be composed of multiple access networks that provide content such as voice, data, video, message, broadcast, etc. to multiple users. For example, the communication network 12 may adopt one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal frequency division multiple access (OFDMA), single carrier frequency division multiple access (SC-FDMA), etc. Further, the communication network 12 may include other core networks, such as, for example, the Internet, a sensor network, an industrial control network, a personal area network, a converged personal network, a satellite network, a home network, or an enterprise network.

[0215] As in Fig.22A As shown in FIG. 1 , the M2M / IoT / WoT communication system 10 may include an infrastructure domain and a field domain. The infrastructure domain refers to the network side of the end-to-end M2M deployment, and the field domain refers to the local area network, usually behind the M2M gateway. Both the field domain and the infrastructure domain may include various different network nodes (e.g., servers, gateways, devices, etc.). For example, the field domain may include an M2M gateway 14 and a terminal device 18. It is to be understood that any number of M2M gateway devices 14 and M2M terminal devices 18 may be included in the M2M / IoT / WoT communication system 10 as desired. Each of the M2M gateway devices 14 and the M2M terminal devices 18 is configured to send or receive signals via the communication network 12 or a direct radio link by using a communication circuit. The M2M gateway 14 allows wireless M2M devices (e.g., cellular and non-cellular) and fixed network M2M devices (e.g., PLC) to communicate with each other through an operator network (such as, the communication network 12 or a direct radio link). For example, the M2M terminal device 18 may collect data and send the data to the M2M application 20 or other M2M devices 18 via the communication network 12 or a direct radio link. The M2M terminal device 18 may also receive data from the M2M application 20 or the M2M terminal device 18. Further, as described below, data and signals may be sent to and received from the M2M application 20 via the M2M service layer 22. The M2M terminal device 18 and the gateway 14 may communicate via various networks including, for example, a cellular network, a WLAN, a WPAN (e.g., Zigbee, 6LoWPAN, Bluetooth), a direct radio link, and a wired network.

[0216] Exemplary M2M end devices 18 include, but are not limited to, tablets, smart phones, medical devices, temperature and weather monitors, connected vehicles, smart meters, game consoles, personal digital assistants, health and fitness monitors, lights, thermostats, appliances, garage doors and other actuator-based devices, security devices, and smart sockets.

[0217] Reference Fig. 22B The illustrated M2M service layer 22 in the field domain provides services for the M2M applications 20 , the M2M gateway devices 14 , and the M2M terminal devices 18 and the communication network 12 . The communication system 12 may be used to implement the functionality of the disclosed embodiments and may include functional and logical entities such as PCRF 702, 914 and 1908, MTC-IWF 704, PCEF 706, 912 and 2002, charging entity 916, 3GPP CN 910, SD-CS 602, SD-ODS 608, SD-OFCS 606, SD-CTF 610, 1302 and 1902, SD-CCF 1102, M2M application 1108, charging SC 1202, service charging and settlement CSF 1604, network service exposure CSF 1606, 3GPP CN 1906, service layer 904, 1600, 1904, ACC 2104, service exposure component 2104, logic at UE 906, and logic for generating interfaces such as interfaces 2302 and 2304. The M2M service layer 22 may be implemented by one or more servers, computers, devices, virtual machines (eg, cloud / storage farms, etc.), including, for example, those described below. Fig. 22C and Fig.22D 14 . It is to be understood that the M2M service layer 22 may communicate with any number of M2M applications, M2M gateways 14, M2M terminal devices 18, and communication networks 12 as desired. The M2M service layer 22 may be implemented by one or more nodes of the network (which may include servers, computers, devices, etc.). The M2M service layer 22 provides service capabilities applied to the M2M terminal devices 18, the M2M gateway devices 14, and the M2M applications 20. The functions of the M2M service layer 22 may be implemented in various ways, for example, as a web server, in a cellular core network, in a cloud, etc.

[0218] Similar to the illustrated M2M service layer 22, there is an M2M service layer 22' in the infrastructure domain. The M2M service layer 22' provides services for the M2M applications 20' and the underlying communication network 12' in the infrastructure domain. The M2M service layer 22' also provides services for the M2M gateway devices 14 and the M2M terminal devices 18 in the field domain. It is to be understood that the M2M service layer 22' can communicate with any number of M2M applications, M2M gateways, and M2M devices. The M2M service layer 22' can interact with the service layer through different service providers. The M2M service layer 22' can be implemented by one or more nodes of the network (which may include servers, computers, virtual machines (e.g., cloud computing / storage farms), etc.).

[0219] Still refer to Fig. 22B , the M2M service layers 22 and 22' provide a core set of service delivery capabilities that different applications and verticals can utilize. These service capabilities enable M2M applications 20 and 20' to interact with devices and perform functions such as data collection, data analysis, device management, security, accounting, service / device discovery, etc. In essence, these service capabilities free applications from the burden of implementing these functions, thereby simplifying application development and reducing the cost and time to market. The service layers 22 and 22' also enable M2M applications 20 and 20' to communicate over various networks 12 and 12' in conjunction with the services provided by the service layers 22 and 22'.

[0220] The method of the present application can be implemented as part of the service layer 22 and 22'. The service layer 22 and 22' are software middleware layers that support value-added services through a collection of application programming interfaces and underlying networking interfaces. Both ETSI M2M and oneM2M use a service layer that can include the connection method of the present application. The service layer of ETSI M2M is called the Service Capability Layer (SCL). The SCL can be implemented in an M2M device (where the SCL is called a device SCL (DSCL)), a gateway (where the SCL is called a gateway SCL (GSCL)) and / or a network node (where the SCL is called a network SCL (NSCL)). The oneM2M service layer supports a set of public service functions (CSFs) (e.g., service capabilities). An instantiation of a set of one or more specific types of CSFs is called a public service entity (CSE), which can be hosted on different types of network nodes (e.g., infrastructure nodes, intermediate nodes, application-specific nodes). Further, the connection method of the present application may be implemented as part of an M2M network that uses a service-oriented architecture (SOA) and / or a resource-oriented architecture (ROA) to access services (such as the connection method of the present application).

[0221] In some embodiments, M2M applications 20 and 20' may be used in conjunction with the disclosed systems and methods. M2M applications 20 and 20' may include applications that interact with a UE or a gateway, and may also be used in conjunction with other disclosed systems and methods.

[0222] In one embodiment, Fig. 22B As shown, logical entities (such as PCRF 702, 914 and 1908, MTC-IWF 704, PCEF 706, 912 and 2002, charging entity 916, 3GPP CN 910, SD-CS 602, SD-ODS 608, SD-OFCS 606, SD-CTF 610, 1302 and 1902, SD-CCF 1102, M2M application 1108, charging SC 1202, service charging and settlement CSF 1604, network service exposure CSF 1606, 3GPP CN 1906, service layer 904, 1600, 1904, ACC 2104, service exposure component 2104, in UE 906, and logic for generating interfaces such as interfaces 2302 and 2304). For example, logical entities (such as PCRF 702, 914 and 1908, MTC-IWF 704, PCEF 706, 912 and 2002, charging entity 916, 3GPP CN 910, SD-CS 602, SD-ODS 608, SD-OFCS 606, SD-CTF 610, 1302 and 1902, SD-CCF 1102, M2M application 1108, charging SC 1202, service charging and settlement CSF 1604, network service exposure CSF 1606, 3GPPCN 1906, service layer 904, 1600, 1904, ACC 2104, service exposure component 2104, in UE The logic at 906, and logic for generating interfaces such as interfaces 2302 and 2304) may be included as a separate service capability within an M2M service layer instance or as a sub-function within an existing service capability.

[0223] The M2M applications 20 and 20' may include applications in various industries such as, but not limited to, transportation, health and wellness, connected home, energy management, asset tracking, and security and monitoring. As mentioned above, the M2M service layer running across devices, gateways, servers, and other nodes of the system supports functions such as, for example, data collection, device management, security, accounting, location tracking / geofencing, device / service discovery, and legacy system integration, and provides these functions as services to the M2M applications 20 and 20'.

[0224] In general, the service layer 22 and 22 'defines a software middleware layer that supports value-added services through a collection of application programming interfaces and underlying networking interfaces. Both the ETSI M2M and oneM2M architectures define a service layer. The service layer of ETSI M2M is called a service capability layer (SCL). The SCL can be implemented in various different nodes of the ETSI M2M architecture. For example, an instance of the service layer can be implemented in an M2M device (where the SCL is called a device SCL (DSCL)), a gateway (where the SCL is called a gateway SCL (GSCL)) and / or a network node (where the SCL is called a network SCL (NSCL)). The oneM2M service layer supports a collection of public service functions (CSFs) (i.e., service capabilities). An instantiation of a collection of one or more specific types of CSFs is called a public service entity (CSE), which can be hosted on different types of network nodes (e.g., infrastructure nodes, intermediate nodes, application-specific nodes). The Third Generation Partnership Project (3GPP) also defines an architecture for machine type communications (MTC). In this architecture, the service layer and the service capabilities it provides are implemented as part of a service capability server (SCS). Whether embodied in the DSCL, GSCL or NSCL of the ETSI M2M architecture, the service capability server (SCS) of the 3GPP MTC architecture, the CSF or CSE of the oneM2M architecture, or in some other node of the network, an instance of the service layer can be implemented as a logical entity (e.g., software, computer executable instructions, etc.) executed on one or more independent nodes (including servers, computers, and other computing devices or nodes) in the network, or as part of one or more existing nodes. As an example, the service layer can be implemented in accordance with the following description in the embodiment of the present invention. Fig. 22C or Fig.22D An instance of the service layer or components thereof is implemented in the form of software running on a network node (e.g., server, computer, gateway, device, etc.) of the general architecture shown in FIG.

[0225] Further, logical entities (such as PCRF 702, 914 and 1908, MTC-IWF 704, PCEF 706, 912 and 2002, charging entity 916, 3GPP CN 910, SD-CS 602, SD-ODS 608, SD-OFCS 606, SD-CTF 610, 1302 and 1902, SD-CCF 1102, M2M application 1108, charging SC 1202, service charging and settlement CSF 1604, network service exposure CSF 1606, 3GPP CN 1906, service layer 904, 1600, 1904, ACC 2104, service exposure component 2104, etc.) can be connected to the UE. The logic at 906, and logic for generating interfaces such as interfaces 2302 and 2304) is implemented as part of an M2M network that uses a service-oriented architecture (SOA) and / or a resource-oriented architecture (ROA) to access the services of the present application.

[0226] Fig. 22C is a block diagram of an example hardware / software architecture of an M2M network node 30 (such as an M2M device 18 , an M2M gateway 14 , an M2M server, etc.). The node 30 may execute or include logical entities (such as PCRF 702, 914 and 1908, MTC-IWF 704, PCEF 706, 912 and 2002, charging entity 916, 3GPP CN 910, SD-CS 602, SD-ODS 608, SD-OFCS 606, SD-CTF 610, 1302 and 1902, SD-CCF 1102, M2M application 1108, charging SC 1202, service charging and settlement CSF 1604, network service exposure CSF 1606, 3GPP CN 1906, service layer 904, 1600, 1904, ACC 2104, service exposure component 2104, logic at UE 906, and logic for generating interfaces such as interfaces 2302 and 2304). The device 30 may be as shown in FIG. 22A to FIG. 22B A portion of an M2M network or a portion of a non-M2M network as shown in Fig. 22C As shown in FIG. 1 , the M2M node 30 may include a processor 32, non-removable memory 44, removable memory 46, a speaker / microphone 38, a keypad 40, a display, a touchpad, and / or an indicator 42, a power supply 48, a global positioning system (GPS) chipset 50, and other peripherals 52. The node 30 may also include communication circuits such as a transceiver 34 and a transmit / receive element 36. It is to be understood that the M2M node 30 may include any sub-combination of the above elements while remaining consistent with the embodiment. The node may be a node that implements the SMSF functionality described herein.

[0227] The processor 32 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. In general, the processor 32 may execute computer executable instructions stored in a memory (e.g., memory 44 and / or memory 46) of the node to perform various required functions of the node. For example, the processor 32 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the M2M node 30 to operate in a wireless or wired environment. The processor 32 may run an application layer program (e.g., a browser) and / or a radio access layer (RAN) program and / or other communication programs. For example, the processor 32 may also perform security operations (e.g., authentication, security key negotiation, and / or encryption operations) such as, for example, in the access layer and / or application layer.

[0228] As in Fig. 22C As shown in FIG. 1 , processor 32 is coupled to its communication circuitry (e.g., transceiver 34 and transmit / receive element 36). By executing computer executable instructions, processor 32 can control the communication circuitry to enable node 30 to communicate with other nodes via the network to which it is connected. Specifically, processor 32 can control the communication circuitry to perform the sending and receiving steps described herein and in the claims. Although Fig. 22C The processor 32 and the transceiver 34 are depicted as separate components, but it is to be understood that the processor 32 and the transceiver 34 may be integrated together in an electronic package or chip.

[0229] The send / receive element 36 may be configured to send signals to other M2M nodes (including M2M servers, gateways, devices, etc.) or receive signals from other M2M nodes (including M2M servers, gateways, devices, etc.). For example, in an embodiment, the send / receive element 36 may be an antenna configured to send and / or receive RF signals. The send / receive element 36 may support various networks and air interfaces, such as WLAN, WPAN, cellular, etc. In an embodiment, for example, the send / receive element 36 may be a transmitter / detector configured to send and / or receive IR signals, UV signals, or visible light signals. In yet another embodiment, the send / receive element 36 may be configured to send and receive both RF signals and optical signals. It is to be understood that the send / receive element 36 may be configured to send and / or receive any combination of wireless signals or wired signals.

[0230] In addition, although Fig. 22C 30 depicts the transmit / receive element 36 as a single element, but the M2M node 30 may include any number of transmit / receive elements 36. More specifically, the M2M node 30 may employ MIMO technology. Therefore, in an embodiment, the M2M node 30 may include two or more transmit / receive elements 36 (e.g., multiple antennas) for transmitting and receiving wireless signals.

[0231] The transceiver 34 may be configured to modulate signals to be transmitted by the transmit / receive element 36 and to demodulate signals received by the transmit / receive element 36. As mentioned above, the M2M node 30 may have multi-mode capabilities. Thus, for example, the transceiver 34 may include multiple transceivers for enabling the M2M node 30 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

[0232] The memory 32 can access information from any suitable memory and can store data in any suitable memory, such as the non-removable memory 44 and / or the removable memory 46. For example, as described above, the processor 32 can store the session context in its memory. The non-removable memory 44 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 32 can access information from a memory that is not physically located on the M2M node 30 (such as, located on a server or a home computer) and can store data in the memory. The processor 32 can be configured to control the lighting mode, image or color on the display or indicator 42 to reflect the state of the M2M service layer session migration or to obtain input from the user or display information about the node's session migration or sharing capabilities or settings to the user. In another example, the display can show information about the session state. The present disclosure defines a RESTful user / application API in the oneM2M embodiment. A graphical user interface, which may be shown on a display, may be layered on top of the API to allow a user to interactively establish and manage E2E sessions, or migration or sharing thereof, via the underlying service layer session functionality described herein.

[0233] The processor 32 may receive power from the power source 48 and may be configured to distribute and / or control the power provided to other components in the M2M node 30. The power source 48 may be any suitable device for powering the M2M node. For example, the power source 48 may include one or more dry cell batteries (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0234] Processor 32 may also be coupled to a GPS chipset 50 that is configured to provide location information (eg, longitude and latitude) regarding the current location of M2M node 30. It will be appreciated that M2M node 30 may acquire location information by any suitable location determination method while remaining consistent with an embodiment.

[0235] The processor 32 may be further coupled to other peripherals 52, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 52 may include an accelerometer, an electronic compass, a satellite transceiver, a sensor, a digital camera (for photos or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, (Bluetooth) modules, frequency modulation (FM) radio units, digital music players, media players, video game player modules, Internet browsers, etc.

[0236] Fig.22D is a block diagram of an exemplary computing system 90 that may also be used to implement one or more nodes of an M2M network (such as an M2M server, gateway, device, or other node). The computing system 90 may include a computer or server and may be primarily controlled by computer-readable instructions, which may be in the form of software (regardless of where such software is stored and how it is accessed). The computing system 90 may execute or include logical entities, such as PCRF 702, 914 and 1908, MTC-IWF 704, PCEF 706, 912 and 2002, charging entity 916, 3GPP CN 910, SD-CS 602, SD-ODS 608, SD-OFCS 606, SD-CTF 610, 1302 and 1902, SD-CCF 1102, M2M application 1108, charging SC 1202, service charging and settlement CSF 1604, network service exposure CSF 1606, 3GPP CN 1906, service layer 904, 1600, 1904, ACC 2104, service exposure component 2104, logic at UE 906, and logic for generating interfaces such as interfaces 2302 and 2304. The computing system 90 may be an M2M device, user equipment, gateway, UE / GW, or any other node (including, for example, a node of a mobile core network, a service layer network application provider, a terminal device 18, or an M2M gateway device 14). Such computer-readable instructions may be executed in a processor, such as a central processing unit (CPU) 91, to cause the device 90 to operate. In many known workstations, servers, and personal computers, the central processing unit 91 is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit 91 may include multiple processors. The coprocessor 81 is an optional processor different from the main CPU 91, which performs additional functions or assists the CPU 91. The CPU 91 and / or the coprocessor 81 may receive, generate, and process data related to the disclosed system and method for E2EM2M service layer sessions (such as receiving session credentials or authenticating based on session credentials).

[0237] In operation, the CPU 91 retrieves, decodes and executes instructions, and transmits information to and from other resources via the computer's primary data transfer path (system bus 80). Such a system bus connects components in the computing system 90 and defines a medium for data exchange. The system bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0238] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes a circuit system that allows information to be stored and retrieved. ROM 93 generally contains stored data that cannot be easily modified. The data stored in RAM 82 can be read or changed by CPU 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that converts a virtual address into a physical address when an instruction is executed. The memory controller 92 can also provide a memory protection function that separates processes within the system and separates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by the virtual address space of its own process; it cannot access memory within the virtual address space of another process unless memory sharing between processes has been set.

[0239] In addition, the computing system 90 may include a peripheral controller 83 that is responsible for transmitting instructions from the CPU 91 to peripherals such as a printer 94 , a keyboard 95 , a mouse 95 , and a disk drive 85 .

[0240] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The display 86 may be implemented with a CRT-based video display, an LCD-based flat panel display, a plasma-based flat panel display, or a touch panel. The display controller 96 includes the electronic components required to generate the video signals sent to the display 86.

[0241] Further, the computing system 90 may include communication circuits (such as, for example, a network adapter 97) that may be used to connect the computing system 90 to an external communication network (such as, Fig.22A and Fig. 22B network 12) to enable computing system 90 to communicate with other nodes of the network.

[0242] User Equipment (UE) can be any device used by an end user for communication. It can be a handheld phone, a laptop equipped with a mobile broadband adapter, or any other device. For example, a UE can be implemented as Figures 22A to 22B M2M terminal device or Fig. 22C Device 30.

[0243] It is to be understood that any or all systems, methods and processes described herein may be embodied in the form of computer executable instructions (e.g., program codes) stored on a computer-readable storage medium, which instructions are executed and / or implement the systems, methods and processes described herein when executed by a machine (e.g., a node of an M2M network, including, for example, an M2M server, a gateway, a device, etc.). Specifically, any steps, operations or functions described above (including the operation of any node of a gateway, UE, UE / GW, or a mobile core network, a service layer or a network application provider) may be implemented in the form of such computer executable instructions. Logical entities (such as PCRF 702, 914 and 1908, MTC-IWF 704, PCEF 706, 912 and 2002, charging entity 916, 3GPP CN 910, SD-CS 602, SD-ODS 608, SD-OFCS 606, SD-CTF 610, 1302 and 1902, SD-CCF 1102, M2M application 1108, charging SC 1202, service charging and settlement CSF 1604, network service exposure CSF1606, 3GPP CN 1906, service layer 904, 1600, 1904, ACC 2104, service exposure component 2104, logic at UE 906, and logic for generating interfaces such as interfaces 2302 and 2304) can be embodied in the form of computer-executable instructions stored on a computer-readable storage medium. Computer-readable storage media include both volatile and nonvolatile, removable and non-removable media implemented in any non-transitory (i.e., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage device, magnetic cassette, magnetic tape, magnetic disk storage device or other magnetic storage device, or any other physical medium that can be used to store the desired information and can be accessed by a computer.

[0244] In describing preferred embodiments of the subject matter of the present disclosure, as illustrated in the accompanying drawings, specific terminology is employed for clarity. However, the claimed subject matter is not intended to be limited to the specific terminology selected, and it is to be understood that each specific element includes all technical equivalents that accomplish a similar purpose in a similar manner.

[0245] This written description uses examples to disclose the invention, including the best mode, and enables any person skilled in the art to practice the invention, including making and using any device or system and performing any included method. The scope of patent protection of the present invention is defined by the claims and may include other examples that may occur to a person skilled in the art. If such other examples have structural elements that do not differ from the literal language of the claims or if they include equivalent structural elements that do not differ substantially from the literal language of the claims, then they are intended to fall within the scope of the claims.< / eventconfig> < / statscollect> < / chargingcorrelationrule> < / eventconfig> < / statscollect> < / eventconfig> < / statscollect> < / chargingcorrelationtrigger> < / chargingcorrelationrule> < / chargingcorrelationtrigger> < / chargingcorrelationtrigger> < / chargingcorrelationrule> < / ae> < / remotecse> < / csebase> < / chargingcorrelationrule> < / chargingcorrelationrule> < / eventconfig> < / statscollect> < / ae> < / remotecse> < / csebase> < / ae> < / remotecse> < / csebase> < / statscollect> < / eventconfig> < / statscollect> < / eventconfig> < / chargingcorrelationtrigger> < / chargingcorrelationrule> < / statscollect> < / eventconfig>

Claims

1. A method comprising: setting a trigger in an underlying 3GPP network via an M2M / IoT service in the network, the M2M / IoT service supporting service capabilities through a set of application programming interfaces (APIs), the M2M / IoT service residing on a server interacting with the underlying 3GPP network to provide the service, wherein the trigger defines that a QoS parameter bound to a charging policy of the underlying 3GPP network has changed in the underlying 3GPP network, and wherein the underlying 3GPP network is configured with a function of sending a notification to the M2M / IoT service upon detecting that the QoS parameter bound to the underlying network charging policy has changed; receiving a notification from the underlying 3GPP network that the trigger has occurred; and An operation responsive to the received notification is performed at the M2M / IoT service residing on the server.

2. The method according to claim 1, wherein: The operation is to update the charging policy.

3. The method according to claim 1, wherein: The notification includes an indication of the data rate.

4. The method according to claim 1, wherein: The operation is to update the data rate of the stream.

5. The method according to claim 1, wherein: The notification includes an indication of the amount of data.

6. The method according to claim 1, wherein: The operation is an update that changes the QoS treatment of a flow.

7. The method according to claim 1, wherein: The operation is to update the billing information record or update the billing operation.

8. A server providing an M2M / IoT service in a network, the service supporting service capabilities through a set of application programming interfaces (APIs), the server comprising a processor and a non-transitory memory comprising computer executable instructions, the computer executable instructions, when executed by the processor, causing the server to: sending, via the server interacting with the underlying 3GPP network to provide the service, a trigger request to the underlying 3GPP network, wherein: The trigger defines that a QoS parameter bound to a charging policy of the underlying 3GPP network has changed in the underlying 3GPP network, and wherein the underlying 3GPP network is configured with functionality to send a notification to the M2M / IoT service upon detecting that the QoS parameter bound to the underlying network charging policy has changed; receiving a notification from the underlying 3GPP network that the trigger has occurred; and An operation responsive to the received notification is performed at the M2M / IoT service residing on the server.

9. The server according to claim 8, wherein: The operation is to update the charging policy.

10. The server according to claim 8, wherein: The notification includes an indication of the data rate.

11. The server according to claim 8, wherein: The operation is to update the data rate of the stream.

12. The server according to claim 8, wherein: The notification includes an indication of the amount of data.

13. The server according to claim 8, wherein: The operation is an update that changes the QoS treatment of a flow.

14. The server according to claim 8, wherein: The operation is to update the billing information record or update the billing operation.

15. A method comprising: receiving, at an underlying 3GPP network, a trigger request from an M2M / IoT service in the network, the service supporting service capabilities through a set of application programming interfaces (APIs), the M2M / IoT service residing on a server interacting with the underlying 3GPP network, the trigger defining a change event that a QoS parameter bound to a charging policy of the underlying 3GPP network has changed in the underlying 3GPP network, and the underlying 3GPP network being configured with functionality to send a notification to the M2M / IoT service upon detecting a QoS parameter change event; generating a notification at the underlying 3GPP network based on a detected occurrence of a QoS parameter change event; and The notification is sent from the underlying 3GPP network to the M2M / IoT service as a result of a detected QoS parameter change event.

16. The method according to claim 15, wherein: The notification includes an indication of the data rate.

17. The method according to claim 15, wherein: The notification is an indication that the M2M / IoT service is to change the data rate of a flow.

18. The method according to claim 15, wherein: The notification is an indication that the M2M / IoT service is to change the QoS treatment of the flow.

19. The method according to claim 15, wherein: The operation performed at the M2M / IoT service in response to the received notification is to update a charging information record or update a service charging operation.

20. An underlying 3GPP network having support functionality for communicating with an M2M / IoT service in the network, the service supporting service capabilities through a set of application programming interfaces (APIs) for updating charging operations, the underlying 3GPP network comprising a processor and a non-transitory memory including computer executable instructions that, when executed by the processor, cause the underlying 3GPP network to: receiving, at the underlying 3GPP network, a trigger request from the M2M / IoT service, the M2M / IoT service residing on a server interacting with the underlying 3GPP network, the trigger request defining a change event that a QoS parameter bound to a charging policy of the underlying 3GPP network has changed in the underlying 3GPP network, and the underlying 3GPP network is configured with functionality to send a notification to the M2M / IoT service upon detection of a QoS parameter change event; generating a notification at the underlying 3GPP network based on a detected occurrence of a QoS parameter change event; and The notification is sent from the underlying 3GPP network to the M2M / IoT service as a result of a detected QoS parameter change event.

Images