Patent Grant
11277522
Machine-to-machine (M2M) technologies allow devices to communicate more directly with each other using wired and wireless communications systems. M2M technologies enable further realization of the Internet of Things (IoT), a system of uniquely identifiable objects and virtual representations of such objects that communicate over a network, such as the Internet. IoT may facilitate communication with even mundane everyday objects, such as products in a grocery store, and thereby reduce costs and waste by improving knowledge of such objects. For example, stores may maintain very precise inventory data by being able to communicate with, or obtain data from, objects that may be in inventory or may have been sold. M2M technologies introduce new challenges in charging for services, such as determining who can charge for services, who should be charged for such services, and what operations are chargeable.
Disclosed herein are methods, devices, and systems related to a service domain charging system that can interact with underlying networks. A service domain charging architecture may include several logical functions, including a Service Domain Charging Management (SD-CM), a Service Domain Online Charging System (SD-OCS), a Service Domain Offline Charging System (SD-OFCS), and a Service Domain Charging Trigger Function (SD-CTF). Service-based charging types may be created and applied to existing event, session, online, and offline charging mechanisms. Service domain charging messages may be exchanged over the X, Y, Z reference points. An E reference point may be used for interfacing with a service domain billing system, and a B reference point may be used between a service domain billing system and the underlying network's billing system.
One embodiment is a method including receiving a policy at a service domain charging management function in a service layer of an M2M network. This policy is defined as a rule with associated attributes. The method also includes using the policy to determine chargeable events within the service layer of the M2M network.
An exemplary charging system for an M2M service domain can include a service domain charging management function to store charging policies for the service domain; a service domain on-line charging system receiving service requests from the service domain charging management function and checking the credit for the requested service before granting the service; and a service domain off-line charging system receiving charging events from the service domain charging management function and producing service domain charging data records.
One embodiment is a method including receiving at a service domain charging management function at an infrastructure node charging policies for the service domain. The method can include distributing the policies from the service domain charging management function at the infrastructure node to a service domain charging management function at an end node.
One embodiment is a method including transferring charging information between a service domain charging system in the service layer and a Machine-Type Communications Interworking Function (MTC-IWF) in a 3GPP network across a Tsp reference point. The method also includes using the transferred charging information in the service domain charging system in the service layer or the MTC-IWF in the 3GPP network.
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 be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that solve any or all disadvantages noted in any part of this disclosure.
The European Telecommunications Standards Institute (ETSI) architecture defines an offline charging system for M2M technologies. In some embodiment integrating aspects of this architecture, charging information, in the form of Charging Data Records (CDRs), may be derived from recorded information and transferred to a Charging Server. All information required for charging may first be selected for recording. There may be a one to one mapping between a recorded M2M event and a CDR.
In the M2M service domain, which, as used herein, refers to M2M services provided by an M2M service provider, including the Service Capability Layer (SCL) of the ETSI M2M architecture and the CSE and CSF of a oneM2M architecture, new challenges are presented for charging, as there are more complex stakeholders and new charging scenarios in such embodiments. Table 2 below lists some exemplary charging scenarios at the service domain, each of which may be combined with others (shown in Table 2 or otherwise).
The service domain may use the following functions to support charging:
The above functions may not be sufficiently addressed by existing charging systems. A 3GPP charging system may not address such functions and may not be applicable to service domain charging. ETSI M2M charging may only provide limited charging functions. ETSI M2M defines simple information recording at the network service capability layer and only addresses offline charging. It does not provide any mechanisms for charging policy control. ETSI M2M also may not define a mechanism to re-use 3GPP charging. Therefore, ETSI M2M charging is very basic and may not meet the requirements of a complete M2M charging system. oneM2M, as a new standard under development, has not yet defined any charging functions and procedures.
Therefore, according to the embodiments set forth herein, mechanisms may be used for a service domain charging system that may interact with one or more underlying networks. More specifically, embodiments are described herein that provide for an overall service domain charging architecture, defining logical functions (e.g., SD-CM, SD-OCS, SD-OFCS and SD-CTF), their functionalities, and their relationships. Embodiments are also described herein that define a service based charging type and that apply existing event, session, online, and/or offline charging in the context of service domain. Embodiments are also described herein that define service domain charging messages over the X, Y, Z reference points. Furthermore, the current disclosure describes an E reference point for interfacing with a service domain billing system and a B reference point between the service domain billing system and an underlying network's billing system. The current disclosure also sets forth an architecture, messages, and interactions with the 3GPP charging system. Embodiments are further set forth for ETSI M2M charging. Defined resource (i.e., data) structure and procedures supporting the disclosed mechanisms are also set forth herein. Note that while the terms used herein may be associated with the oneM2M architecture, standards, and related documents, the presently disclosed embodiments may be applied to any service domain charging system.
Various charging types may be supported at the service domain in the embodiments described herein. Each may support the possible charging scenarios described above in Table 2. The terms used in 3GPP charging may be used herein for simplicity, such as Online/Offline charging, with the functionalities expanded according to the described embodiments to provide more flexibility in the service domain for new charging scenarios. A service based charging type is set forth herein to satisfy service domain requirements.
In addition to the traditional session-based and event-based charging, the service domain may provide unique service-based charging. Since a CSE may contain many different CSFs, and it may also manage “big” data, a CSE may perform a complex request that involves a series of actions, multiple inputs, and multiple decisions. Such a request may result in the requestor being charged by the service rather than for one or more steps of an operation.
A service domain may have its own sessions or may be session-less. In the context of charging, the term “session” as used herein has a broad scope. A service session may be a subscriber's subscription to a specific service provider and/or it may be a logical service connection. A subscriber may have multiple service connections. For example, a service registration may be in process, such as when a CSE in an end node registers to a CSE in an infrastructure node. Such registration may be considered a session and charging may be done per registration. A session may be identified by a unique service session identifier (ID) and may be associated with a subscriber ID, a session duration, a service session QoS, and/or other information that may affect charging.
Service Domain Events may refer to non-continuous transactions, such as an operation on data (e.g., Create, Update, Retrieval, etc.).
Service domain charging methods may be divided into Online and Offline charging, in some embodiments based on how charging affects real time services, similar to the concepts of Online and Offline charging in 3GPP. Offline charging may not affect services provided in real time. Charging triggering information may be generated at the CSFs where it happens. A charging report with Offline charging data may be passed via different nodes to the network to generate Service Domain CDRs (SD-CDRs). Online charging may affect services granted in real time. A service request may first be generated and the requestor's credit may be checked before the service is granted. Whether a service uses Online or Offline charging may be based on service sessions or events. For example, an application may create data in the service domain and specify that reading the data is event-based Online charging with a certain rate. A subscriber (e.g., a user, an application) may be charged by using a combination of both Online and Offline charging mechanisms.
The Service Domain Charging System (SD-CS) may consist of four logical functions.
The Service Domain Charging Management (SD-CM) 502 may be central to SD-CS. The SD-CM 502 may contain charging policies that the CSE 506 supports. It may obtain charging policies by provisioning and/or configuration. The policies may be obtained from the service provider or they may be configured by an application 508 or another CSE 510. The SD-CM 502 may also update its policy based on statistics of chargeable events at the service layer. The SD-CM 502 may have internal interfaces with other CSFs in the same CSE 506. The SD-CM 502 may configure other CSFs 504 regarding chargeable events and policies.
The SD-CM 502 may serve as the aggregator and dispatcher of charging information. It may receive charging requests and events from other CSFs 504. The SD-CM 502 may dispatch the requests to either Service Domain Online Charging System (SD-OCS) 512 or the Service Domain Offline Charging System (SD-OFCS) 514. The SD-CM 502 may get output from the SD-OCS 512 and/or the SD-OFCS 514 and may send the information to either the Service Billing Domain or an underlying network's charging system, based on the policy. The SD-CM 502 may be the anchor point for interactions among the SD-CS in different nodes (such as infrastructure nodes, intermediate nodes, and end nodes). The SD-CM 502 may also be the anchor point for the SD-CS to interface and interact with an underlying network for charging related operations.
The Service Domain Offline Charging System (SD-OFCS) 514 may receive offline charging events from a SD-CM 502 and generate SD-CDRs and SD-CDR files. The Service Domain Online Charging System (SD-OCS) 512 may receive service requests, check credit, and grant services. The SD-OCS 512 can maintain the credit information for different entities.
An intermediate node or an end node may or may not have one or both of the SD-OFCS 514 and the SD-OCS 512 depending on the deployment. The SD-CM 502 in the infrastructure node may configure the SD-CM 518, SD-OFCS 520, and SD-OCS 522 in the intermediate node 510 and the SD-CM 524, SD-OFCS 526, and SD-OCS 528 in the end node 527 so charging can be done locally in order to reduce traffic between the nodes and increase response time.
One or more Service Domain Charging Trigger Function (SD-CTF) 530, 532, and 534 may reside in the CSFs as shown in the small boxes of
The SD-CS 502 may advertise its charging related information, such as rate, to other CSEs or applications via the Y or X referent point. The SD-CS 502 may utilize the charging and billing system in the underlying networks via the Z reference point. Internal to the SD-CS, the SD-OCS 512 and SD-OFCS 514 may communicate with each other. Further details about such embodiments are provided herein.
The service domain may have its own billing system 536. The SD-CS in the infrastructure node 506 may communicate with the service domain billing system 536 via a reference point referred to as E. The E referent point connects the M2M service domain (e.g., CSEs) to external lateral systems that are not applications or underlying networks. The billing domain may be a third party application, such as PAYPAL. The service domain may exchange charging and billing information with the billing domain via the E reference point. The service domain billing system 536 may also have a B reference point with the billing system 540 in the underlying system since they may come from different providers.
When there is no SD-CM in an end node 527, the SD-CM 518 in the intermediate node 510 or SD-CM 502 in the infrastructure node 527 where the end node registers may act as a proxy and aggregator for charging. Such a SD-CM 518 in the intermediate node 510 or a SD-CM 502 in the infrastructure node 527 may collect charging events and store and apply charging policies for the end nodes. In some cases there is no SD-CTF in the end node 527 as well. The transactions and charging related to the end node 527 may be captured at the intermediate node 510 or infrastructure node 506.
Illustrated in the figures are operations by the SD-CS at the infrastructure node 506 and the end node 527. The same concepts and procedures apply to the intermediate nodes 510. Multi-hop charging operations are possible, for example where the SD-CS in the infrastructure node 506, intermediate node 510, and end node 527 communicate with each other. While the figures show that the charging events may occur at the end node 527, charging events may also occur at the intermediate node 510 or the infrastructure node 506. If they occur at the infrastructure node 506, the SD-CS at the infrastructure node may process the charging information. The SD-CS may choose to push the charging information to the intermediate node 510 or the end node 527 for sharing of information.
Examples of charging policies include supported charging types (e.g., Online, Offline, Service Based), association of subscriber ID and application/subscriber types with charging types (e.g., Online, Offline, Service Based), association of subscriber ID, application/subscriber types, and service domain operations with rate, a list of chargeable events, chargeable event reporting parameters, and credit reservation trigger and threshold.
Note that
At step 3, some of the operations to fulfill the service may be completed. Note that some operations may depend on a credit check being executed. At step 4, the SD-CTF 534 at the CSFs 542 may trigger either charging events for Offline charging or a charging request for Online charging. A service request may involve both Online Charging and Offline Charging. At steps 5, 6, and 7, the SD-CM 524 at the end node 527 may dispatch the service requests for Online charging and charging reports for Offline charging to the respective SD-OCS 512 and SD-OFCS 514 at the infrastructure node 506. It may also aggregate requests and responses. Some of the procedures may be dependent on others. At step 8, other operations completed. The CSF Dispatcher 902 may receive a status. It may also notify the service requestor of the completion of the service.
Table 3 below lists messages that may be used in the service domain charging operations. Key information elements (IEs) are listed to indicate the use of these messages, and other IEs may be included to convey additional information. These messages may be supported by different styles protocols, such as RESTful protocols or based protocols, or other protocols based thereon. A service layer charging system as set forth herein may apply a RESTful architecture or a non-RESTful architecture.
In an embodiment, data structures may be used to support the charging mechanisms disclosed herein. Such data structures may take the form of resources. A resource may be a uniquely addressable object in the RESTful architecture. A resource may have a representation that can be transferred and manipulated with the RESTful verbs (e.g., CREATE, RETRIEVE, UPDATE, DELETE). A resource may be addressed uniquely using a Universal Resource Identifier (URI). A child resource may be a resource that has a containment relationship with an addressed (i.e., parent) resource. The parent resource representation may contain one or more references to sub-resources(s) (i.e., child resources). The lifetime of a child-resource may be limited by the parent's resource lifetime. An attribute may store information, such as meta-data about the resource itself.
Resource-based data structure may make it easier to perform RESTful operations, such as using protocols such as Hypertext Transfer Protocol (HTTP) or Constrained Application Protocol (CoAP). However, such a data structure may also be applied to non-RESTful protocols. A resource may contain child resource(s) and attribute(s).
The defined structure enables flexible and extensible service layer charging mechanisms. The originator may set up charging policies and configurations to the receiver using the chargeConfig resource. Additionally, the originator may set up different charging rules based on the charging configuration and policies. These rules may indicate who (the entity that charges) will charge whom (the entity being charged) based on what (e.g., online or offline charging, event based, service based, or session based charging, etc.). The charging rule enables the system to have different granularities. For example, the charging rule may be based on a logical function, such as a CSE node or an application. The charging rule may also or instead, be based on a resource. For example, the charging rule may be based on an entity that wants to charge every reading operation of a specific resource. Though not shown in the figures, all the resources should support vendor specific attributes/child resources.
As used in the figures, the following shapes illustrate an exemplary, non-limiting resource structure:
In Read/Write access mode, the following values may be assumed:
Table 4 below lists exemplary attributes that may be used for defining a charging rule. Note that the “ID” listed here may be a unique ID, such as a numeric ID, or a uniquely addressable URI that points to the associated resource.
One embodiment can be considered as a multi-step process. Step 1 can be the configuration of what service layer charging types are supported as shown in
Step 2 can be to configure the policy for the chargeable events. Each chargeable event has one instance of the data structure shown in
Step 3 can define the specific scenarios based on the chargeable event defined in step 2 using the data structure shown in
A chargingRate collection resource may define the rate to be charged for a chargeable event or service. The service provider may choose to post the rate to the service entities. The chargingRate resource may associate a specific chargeable event, a subscriber, a service, etc. with the rate. The rate may be specific to other factors, such as a specific time. The rate may be dynamically increased or decreased based on the previous transactions.
ChargingRecords may be created based on the defined <chargingRecordForm>. Each <chargingRecordForm> may define a specific charging record format. ChargingRecords may be the instances created.
In more de-coupled embodiments, the service domain and 3GPP domain may exchange CDRs, integrate the CDRs, and regenerate converged billing information. In more integrated embodiments, the service domain and the 3GPP domain may exchange charging policy information and conduct charging in one domain. Below are listed some of the scenarios involving SD-CS 1702 interworking with the 3GPP charging and billing system:
The presently disclosed embodiments are related to the service domain and impact to the 3GPP domain is described only as necessary. Note that some operations disclosed herein may be performed on more than one reference point. An exemplary list of messages and their applicability to different reference points is provided above in Table 3.
Some embodiments utilize the Tsp interface. In such embodiments, the service domain and the 3GPP domain may exchange charging information. The charging information may be carried in the form of CDRs or CDR files over the Tsp reference point defined in 3GPP. Such scenarios may include:
When an exchange is initiated by SCS 1706, if it is a push, the SD-CS 1702 may include the SD-CDR files in the payload of the CDR Transfer Req message. The 3GPP MTC-IWF 1704 may simply respond to the request or it may also include 3GPP CDR files in the response message. Similar operations may be used in the other direction when 3GPP initiated the exchange. The service domain and 3GPP domain may also exchange charging related policies via Tsp.
Some embodiments utilize the Rx interface. In such embodiments, the Rx reference point may be used for the service domain and the 3GPP domain to exchange charging related policies. The SCS 1706 may subscribe to notifications about 3GPP traffic events. For example, the SCS 1706 may receive a notification that an IP session has been closed or a UE has handed over to a different access technology, and the CSE at the SCS 1706 may take actions to trigger service domain operations. The service domain and the 3GPP domain may exchange session related information over Rx for session based charging.
Some embodiments utilize the Gi/SGi interface. In such embodiments, because the service domain operations are user plane traffic in 3GPP, the service domain may include service domain charging information together with the service domain operations (such as data creation, retrieval) and send the information to the 3GPP domain via Gi/SGi. The Policy and Charging Enforcement Function (PCEF) 1714 may process the information and perform charging at 3GPP.
At steps 1-4, in an embodiment, the 3GPP charging system may be in control of SD-CS 1902. The 3GPP charging policy entity PCRF 1904 may send a charging policy configuration for SD-CS 1902 via the Rx reference point. The SD-CS 1902 may configure its charging policy based on input from the 3GPP charging system. At steps 5-8, the MTC-IWF 1906 may send 3GPP charging information to the SD-CS 1902 via the Tsp reference point. For example, the MTC-IWF 1906 may have 3GPP subscriber information and the SD-CS 1902 may associate the 3GPP ID with the service domain IDs. At steps 9-12, the PCRF 1904 may pass 3GPP charging related information to SD-CS 1902, such as session status. The SD-CS 1902 may take actions according to its policies. For example, SD-CS 1902 may apply a different rate when a 3GPP session has been handed over to another access technology. At steps 13-15, in some embodiments, the SD-CS 1902 may attach service domain charging information in the service domain operation messages over the user plane reference point Gi/SGi to PCEF 1908. Charging may be performed at the PCEF 1908 and the information may be sent back to SD-CS 1902 over the user plane.
Table 10 below lists exemplary messages related to charging that may be exchanged between the 3GPP domain and the service domain.
Table 11 below lists exemplary non-limiting potential charging events that may be supported by an ETSI M2M charging system according to one embodiment.
Interfaces, such as interfaces 2302, 2304 and 2306, can be used to view information related to the service domain charging system discussed above. Interfaces, such as interfaces 2302, 2304 and 2306, can also be used to configure and set data related to the service domain charging system discussed above. For example, such interfaces can be used to set charging related values for the system.
As shown in
As shown in
Referring to
Referring also to
In some embodiments, M2M applications 20 and 20′ may include the applications that interact with capillary devices and therefore may be used in conjunction with the disclosed systems and methods for capillary device charging. The M2M applications 20 and 20′ may include the applications that interact with the UE or gateway and may also be used in conjunction with other disclosed charging systems and methods. The M2M applications 20 and 20′ may include applications in various industries such as, without limitation, transportation, health and wellness, connected home, energy management, asset tracking, and security and surveillance. As mentioned above, the M2M service layer, running across the devices, gateways, and other servers of the system, supports functions such as, for example, data collection, device management, security, billing, location tracking/geofencing, device/service discovery, and legacy systems integration, and provides these functions as services to the M2M applications 20 and 20′.
Generally, the service layers 22 and 22′ define a software middleware layer that supports value-added service capabilities through a set of Application Programming Interfaces (APIs) and underlying networking interfaces. Both the ETSI M2M and oneM2M architectures define a service layer. ETSI M2M's service layer is referred to as the Service Capability Layer (SCL). The SCL may be implemented within an M2M device (where it is referred to as a device SCL (DSCL)), a gateway (where it is referred to as a gateway SCL (GSCL)) and/or a network node (where it is referred to as a network SCL (NSCL)). The oneM2M service layer supports a set of Common Service Functions (CSFs) (i.e. service capabilities). An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE) which can be hosted on different types of network nodes (e.g. infrastructure node, middle node, application-specific node). The Third Generation Partnership Project (3GPP) has also defined an architecture for machine-type communications (MTC). In that architecture, the service layer, and the service capabilities is provides, are implemented as part of a Service Capability Server (SCS). Whether embodied in a DSCL, GSCL, or NSCL of the ETSI M2M architecture, in a Service Capability Server (SCS) of the 3GPP MTC architecture, in a CSF or CSE of the oneM2M architecture, or as some other component or module of a network, the service layer may be implemented as a logical entity (e.g., software, computer-executable instructions, and the like) executing either on one or more standalone servers, computers, or other computing devices or nodes in the network or as part of one or more existing servers, computers, or nodes of such network. As an example, a service layer or component thereof may be implemented in the form of software running on a server, computer, or device having the general architecture illustrated in
Further, the logical entities of the present application such as Service Domain Charging System, SD-CM 502, SD-OCS 512, SD-OFCS 514, SD-CTF 530, and logic to produce interfaces, such as interfaces 2302, 2304 and 2306 can implemented as part of an M2M network that uses a Service Oriented Architecture (SOA) and/or a resource-oriented architecture (ROA) to access services of the present application.
FIG. --C is a system diagram of an example device 30, that can be an M2M device, user equipment, gateway, UE/GW or any other nodes including nodes of the mobile care network, service layer network application provider, terminal device 18 or an M2M gateway device 14 for example. The device 30 can execute or include logical entities such as such as Service Domain Charging System, SD-CM 502, SD-OCS 512, SD-OFCS 514, SD-CTF 530, and logic to produce interfaces, such as interfaces 2302, 2304 and 2306. The device 30 can be part of an M2M network as shown in
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 in association with a DSP core, a controller, a microcontroller, one or more Application Specific Integrated Circuits (ASICs), one or more Field Programmable Gate Array (FPGAs) circuits, any other type and number of integrated circuits (ICs), a state machine, and the like. The processor 32 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the device 30 to operate in a wireless environment. The processor 32 may be coupled to the transceiver 34, which may be coupled to the transmit/receive element 36. While
The transmit/receive element 36 may be configured to transmit signals to, and/or receive signals from, an M2M service platform 22. For example, in an embodiment, the transmit/receive element 36 may be an antenna configured to transmit and/or receive RF signals. The transmit/receive element 36 may support various networks and air interfaces, such as WLAN, WPAN, cellular, and the like. In an embodiment, the transmit/receive element 36 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 36 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 36 may be configured to transmit and/or receive any combination of wireless or wired signals.
In addition, although the transmit/receive element 36 is depicted in
The transceiver 34 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 36 and to demodulate the signals that are received by the transmit/receive element 36. As noted above, the device 30 may have multi-mode capabilities. Thus, the transceiver 34 may include multiple transceivers for enabling device 30 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.
The processor 32 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 44 and/or the removable memory 46. The non-removable memory 44 may include random-access memory (RAM), 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, and the like. In other embodiments, the processor 32 may access information from, and store data in, memory that is not physically located on the device 30, such as on a server or a home computer.
The processor 30 may receive power from the power source 48, and may be configured to distribute and/or control the power to the other components in the device 30. The power source 48 may be any suitable device for powering the device 30. 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, and the like.
The processor 32 may also be coupled to the GPS chipset 50, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the device 30. It will be appreciated that the device 30 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.
The processor 32 may further be 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 e-compass, a satellite transceiver, a sensor, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
In operation, CPU 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer's main data-transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. 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 the PCI (Peripheral Component Interconnect) bus.
Memory devices coupled to system bus 80 include random access memory (RAM) 82 and read only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally contain stored data that cannot easily be modified. Data stored in RAM 82 may be read or changed by CPU 91 or other hardware devices. Access to RAM 82 and/or ROM 93 may be controlled by memory controller 92. Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode can access only memory mapped by its own process virtual address space; it cannot access memory within another process's virtual address space unless memory sharing between the processes has been set up.
In addition, computing system 90 may contain peripherals controller 83 responsible for communicating instructions from CPU 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85. Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output may include text, graphics, animated graphics, and video. Display 86 may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86.
Further, computing system 90 may contain network adaptor 97 that may be used to connect computing system 90 to an external communications network, such as network 12 of
It is understood that any or all of the systems, methods, and processes described herein may be embodied in the form of computer executable instructions (i.e., program code) stored on a computer-readable storage medium. Such instructions, when executed by a machine, such as a computer, server, M2M terminal device, M2M gateway device, or the like, perform and/or implement the systems, methods and processes described herein. Specifically, any of the steps, operations or functions described above, including the operations of the gateway, UE, UE/GW, or any of the nodes of the mobile core network, service layer or network application provider, may be implemented in the form of such computer executable instructions. Logical entities s such as Service Domain Charging System, SD-CM 502, SD-OCS 512, SD-OFCS 514, SD-CTF 530, and logic to produce interfaces, such as interfaces 2302, 2304 and 2306 may be embodied in the form of the computer executable instructions. Computer readable storage media include both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of 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 memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other physical medium that can be used to store the desired information and that can be accessed by a computer.
In describing preferred embodiments of the subject matter of the present disclosure, as illustrated in the FIGS., specific terminology is employed for the sake of clarity. The claimed subject matter, however, is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.
This written description uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal languages of the claims.
This application is a continuation of U.S. patent application Ser. No. 14/339,899 “Service Domain Charging Systems and Methods” filed Jul. 24, 2014 which claims the benefit of, and incorporates herein by reference, U.S. Provisional Application 61/886,458 “Service Domain Charging System and Interactions with Underlying Networks” filed Oct. 3, 2013 and U.S. Provisional Application 61/857,912 “Service Domain Charging System and Interactions with Underlying Networks” filed Jul. 24, 2013. The disclosures of each application listed in this paragraph are hereby incorporated by reference as if set forth in their entireties herein.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5943657 | Freestone et al. | Aug 1999 | A |
| 8730823 | Mohammed et al. | May 2014 | B2 |
| 9300531 | D Souza et al. | Mar 2016 | B2 |
| 9425969 | Baer et al. | Aug 2016 | B2 |
| 20070172040 | Cesarini | Jul 2007 | A1 |
| 20080069028 | Richardson | Mar 2008 | A1 |
| 20100039941 | Tan et al. | Feb 2010 | A1 |
| 20110167471 | Riley et al. | Jul 2011 | A1 |
| 20110225306 | Delsesto et al. | Sep 2011 | A1 |
| 20110295935 | Vihtari et al. | Dec 2011 | A1 |
| 20120036257 | Mann et al. | Feb 2012 | A1 |
| 20120109800 | Zhou et al. | May 2012 | A1 |
| 20120149325 | Titus et al. | Jun 2012 | A1 |
| 20120220330 | Goldner et al. | Aug 2012 | A1 |
| 20120231785 | Poon et al. | Sep 2012 | A1 |
| 20120246325 | Pancorbo et al. | Sep 2012 | A1 |
| 20120284777 | Eugenio et al. | Nov 2012 | A1 |
| 20120295585 | Khan | Nov 2012 | A1 |
| 20120327787 | Mohammed et al. | Dec 2012 | A1 |
| 20130054428 | Shaikh | Feb 2013 | A1 |
| 20130174212 | Lalseta et al. | Jul 2013 | A1 |
| 20130176907 | Foti | Jul 2013 | A1 |
| 20130179583 | Foti | Jul 2013 | A1 |
| 20130188554 | Cai et al. | Jul 2013 | A1 |
| 20130203394 | Dong et al. | Aug 2013 | A1 |
| 20130208629 | Luo et al. | Aug 2013 | A1 |
| 20130288668 | Pragada et al. | Oct 2013 | A1 |
| 20130297744 | Foti | Nov 2013 | A1 |
| 20130324078 | Xue et al. | Dec 2013 | A1 |
| 20130343231 | Foti | Dec 2013 | A1 |
| 20140003313 | Jain | Jan 2014 | A1 |
| 20140051384 | Mao et al. | Feb 2014 | A1 |
| 20140056182 | Chai | Feb 2014 | A1 |
| 20140189001 | Tyagi et al. | Jul 2014 | A1 |
| 20140273932 | Sharma et al. | Sep 2014 | A1 |
| 20140273933 | Sharma et al. | Sep 2014 | A1 |
| 20140289803 | Sharma et al. | Sep 2014 | A1 |
| 20140295790 | Vos et al. | Oct 2014 | A1 |
| 20140372287 | Tornkvist | Dec 2014 | A1 |
| 20150011182 | Goldner et al. | Jan 2015 | A1 |
| 20150023219 | Jin et al. | Jan 2015 | A1 |
| 20150071128 | Iwai | Mar 2015 | A1 |
| 20150195671 | Seed et al. | Jul 2015 | A1 |
| 20150229779 | Goermer et al. | Aug 2015 | A1 |
| 20150245205 | Kim et al. | Aug 2015 | A1 |
| 20150333991 | Liu et al. | Nov 2015 | A1 |
| 20150341851 | Cai et al. | Nov 2015 | A1 |
| 20160212567 | Iwai | Jul 2016 | A1 |
| Number | Date | Country |
|---|---|---|
| 103181142 | Jun 2013 | CN |
| 2512106 | Oct 2012 | EP |
| 2014-529383 | Nov 2014 | JP |
| 2011019773 | Feb 2011 | WO |
| 2011134321 | Nov 2011 | WO |
| 2012177665 | Dec 2012 | WO |
| 2015013485 | Jan 2015 | WO |
| Entry |
|---|
| 3GPP TR 29.817 V0.1.0, “3rd Generation Partnership Project; Technical Specification group Core Network and Terminals; Study on XML Based Access of AF to the PCRF (Release 12)”, Jun. 2013, 36 pages. |
| 3rd Generation Partnership Project; (3GPP) TR 23.682 V11.4.0; 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture Enhancements to Facilitate Communications with Packet Data Networks and Applications (Release 11), Jun. 2013, 29 pages. |
| 3rd Generation Partnership Project; (3GPP) TR 23.888 V11.0.0; 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System Improvements for Machine-Type Communications (MTC) (Release 11), Sep. 2012, 165 pages. |
| 3rd Generation Partnership Project; (3GPP) TS 23.203, V12.0.0; 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Policy And Charging Control Architecture, (Release 12), Mar. 2013, 183 pages. |
| 3rd Generation Partnership Project; (3GPP) TS 23.682, V11.3.0; 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture Enhancements To Facilitate Communications With Packet Data Networks And Applications, (Release 11), Dec. 2012, 29 pages. |
| 3rd Generation Partnership Project; (3GPP) TS 29.368 ,V11.2.0; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Tsp interface protocol between the MTC Interworking Function (MTC-IWF) and Service Capability Server (SCS), (Release 11), Mar. 2013, 21 pages. |
| 3rd Generation Partnership Project; (3GPP) TS 32.240, V12.0.0; 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication Management; Charging Management; Charging Architecture and Principles, (Release 12), Mar. 2013, 45 pages. |
| European Telecommunications Standards Institute (ETSI) TS 102 690 V2.0.1; Recording Information for Statistical and Offline Charging in M2M; Ericsson; Machine-to-Machine Communications (M2M); Functional Architecture, Mar. 2012, 9 pages. |
| European Telecommunications Standards Institute (ETSI) TS 102 690, V1.2.1; Machine-to-Machine Communications (M2M); Functional Architecture, Jun. 2013, 279 pages. |
| European Telecommunications Standards Institute (ETSI) TS 102 690, V2.0.14; Technical Specificatio; Machine-to-Machine Communications (M2M); Functional Architecture, Jul. 2013, 332 pages. |
| International Application No. PCT/US2014/047951: International Search Report and Written Opinion dated Jan. 20, 2015, 20 pages. |
| Japanese Application No. 2016-530046: Notice of Reasons for Rejection dated Dec. 26, 2016, 5 pages. |
| One M2M ARC WG2 ARC WG, “List of Common Services Functions—Call for Contributions”, Jul. 11, 2013, 6 pages. |
| OneM2M Technical Specification TS-0001 V 0.0.4, “oneM2M Functional Architecture”, Jun. 28, 2013, 22 pages. |
| OneM2M-TS-0001; OneM2M Functional Architecture V 0.0.3; Jun. 8, 2013, 11 pages. |
| Rapporteur et al., “UCs agreed in TP4 & Table containing Industry Categories in Annex. A”, ONEM2M-REQ-2012-0065RII-USE Case TR.DOC ONEM2M, vol. WGI—Requirements, REQ, May 1, 2013, pp. 1-179, XP084002129. |
| ZTE et al., “This contribution presents extract from 3GPP TS 23.682 (Architecture enhancements to facilitate communications with packet data networks and applications) that relate to architectural enhancements and deployment models for supporting Machine Type Communications (MTC)/M2M services”, ONEM2M-ARC-2012-0008R02—Intro to 3GPP Arch Itecture Enhancements and Deployment Model, S.ZIP, ONEM2M, vol. WG2—Architecture, ARC, Jan. 8, 2013, pp. 1-11, XP084000535. |
| Number | Date | Country | |
|---|---|---|---|
| 20200036837 A1 | Jan 2020 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61886458 | Oct 2013 | US | |
| 61857912 | Jul 2013 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14339899 | Jul 2014 | US |
| Child | 16589605 | US |
