Method, apparatus, and computer-readable storage medium for communicating via a user service platform
阅读说明:本技术 经由用户服务平台通信的方法、装置和计算机可读存储介质 (Method, apparatus, and computer-readable storage medium for communicating via a user service platform ) 是由 T·卡雷 于 2018-04-30 设计创作,主要内容包括:始发用户服务平台(USP)端点将表示USP消息的有效载荷分为较小的分段(也被称为“片段”或“块”),以用于通过具有不同消息大小约束的中间代理来传输有效载荷。在接收到之后,接收USP端点重组该较小的分段以恢复表示所述USP消息的有效载荷。(An originating User Service Platform (USP) endpoint divides the payload representing the USP message into smaller segments (also referred to as "fragments" or "blocks") for transport of the payload by intermediate agents having different message size constraints. Upon receipt, the receiving USP endpoint reassembles the smaller fragments to recover the payload representing the USP message.)
1. An electronic device (102, 104, 106, 108A, and 108B), comprising:
a memory (1004) storing computer readable instructions; and
one or more processors (1002) coupled to the memory, the one or more processors configured to execute the computer-readable instructions to:
segmenting a payload representing a user service platform message to generate a plurality of payload segments, an
Generating a sequence of user service platform records based on the plurality of payload segments, each of the user service platform records comprising: (i) a payload segment from among the plurality of payload segments; and (ii) segmentation and reassembly status information indicating a status of a segment of the payload at the electronic device when the included payload segment is generated; and
a transceiver (1006) coupled to the one or more processors, the transceiver configured to transmit the sequence of user service platform records.
2. The electronic device of claim 1, wherein the plurality of payload segments have a size based on a size of a non-payload portion of the user service platform record and a size of a maximum transfer unit associated with a message transfer protocol used to transfer the sequence of user service platform records.
3. The electronic device of claim 1, wherein the state of the segment is one of: start, process, and finish.
4. The electronic device of claim 1, wherein:
the payload comprises at least a first payload record and a second payload record, the first payload record and the second payload record together representing at least a portion of the user service platform message;
the plurality of payload segments comprises a plurality of first payload segments and a plurality of second payload segments; and
the one or more processors are further configured to execute the computer-readable instructions to segment the first payload record into the plurality of first payload segments and segment the second payload record into the plurality of second payload segments.
5. The electronic device of claim 4, wherein the segmentation and reassembly status information for a first payload segment among the plurality of first payload segments comprises:
a first payload segment and reassembly status indicating a status of the segment of the payload when the first payload segment was generated, an
A first payload record segment and reassembly status indicating a status of the segment of the first payload record when the first payload segment was generated.
6. The electronic device of claim 5, wherein:
the first payload segment and reassembly status indicates a start of the segment of the payload at the electronic device; and/or
The first payload segment and reassembly status indicates an end of the segment of the payload at the electronic device; and/or
The first payload record segment and reassembly status indicates a start of the segment of the first payload record at the electronic device; and/or
The first payload record segment and reassembly status indicates an end of the segment of the first payload record at the electronic device; and/or
Each of the first payload record and the second payload record comprises a transport layer security entity.
7. An electronic device (102, 104, 106, 108A, and 108B), comprising:
a transceiver (1006) configured to receive a sequence of a plurality of user service platform records, each user service platform record of the plurality of user service platform records comprising: (i) a payload segment representing a portion of a user services platform message, and (ii) segmentation and reassembly status information indicating a status of the payload being divided into payload segments at the originating endpoint device; and
one or more processors (1002) coupled to the transceiver, the one or more processors configured to execute the computer-readable instructions to:
buffering the plurality of user service platform records, an
In response to receiving a user service platform record comprising segmentation and reassembly status information, the user service platform message is recovered by reassembling the payload segments of the plurality of user service platform records in the buffer, the segmentation and reassembly status information indicating that segmentation of the payload is complete at the originating endpoint device.
8. The electronic device of claim 7, wherein the segmentation and reassembly status information recorded for each user service platform indicates that the segmentation status of the payload is one of: start, process, and finish.
9. The electronic device of claim 7, wherein:
the payload comprises at least a first payload record;
a first user service platform record of the plurality of user service platform records comprises: (i) a first segment of the first payload record and (ii) first segmentation and reassembly status information; and
the first segmentation and reassembly status information comprises:
a first payload segmentation and reassembly status indicating a status of the segments of the payload when the first segment of the first payload record was generated, an
A first payload record segments and reassembly status indicating a status of the segments of the first payload record when the first segment of the first payload record was generated.
10. The electronic device of claim 9, wherein:
the first payload segment and reassembly status indicates a start of a segment of the payload at the originating endpoint device; and/or
The first payload record segment and reassembly status indicates a start of a segment of the first payload record at the originating endpoint device; and/or
The first payload record comprises a transport layer security entity; and/or
The payload comprises a single payload record representing a user service platform message.
Background
FIELD
One or more example embodiments relate to methods, apparatuses, and/or computer-readable storage media for communicating via a User Service Platform (USP).
Disclosure of Invention
One or more example embodiments provide a mechanism for an originating User Service Platform (USP) endpoint to fragment the payload representing a USP message into smaller fragments (also referred to as "fragments" or "blocks") that permit the payload to be transported through Message Transfer Protocol (MTP) proxies having different message size constraints, and to cause a receiving USP endpoint to reassemble the smaller fragments into a larger payload after receiving the smaller fragments. This process is sometimes referred to herein as a segmentation and reassembly (SAR) function.
At least one example embodiment provides an electronic device, comprising: a memory storing computer readable instructions; one or more processors coupled to the memory; and a transceiver coupled to the one or more processors. The one or more processors are configured to execute the computer-readable instructions to: segmenting a payload representing a user service platform message to generate a plurality of payload segments; and generating a sequence of user service platform records based on the plurality of payload segments, each of the user service platform records comprising: (i) a payload segment from among the plurality of payload segments, and (ii) segment and reassembly status information indicating a status of a segment of the payload at the electronic device at a time the included payload segment was generated. The transceiver is configured to transmit a sequence of user service platform records.
At least one other example embodiment provides an electronic device comprising a transceiver and one or more processors coupled to the transceiver. The transceiver is configured to receive a sequence of a plurality of user service platform records, each of the plurality of user service platform records comprising: (i) a payload segment representing a portion of the user services platform message, and (ii) segmentation and reassembly status information indicating a status of the payload being divided into payload segments at the originating endpoint device. The one or more processors are configured to execute the computer-readable instructions to: buffering a plurality of user service platform records; and, in response to receiving the user service platform record including segmentation and reassembly status information indicating that the segmentation of the payload is completed at the originating endpoint device, recovering the user service platform message by reassembling the payload segments of the plurality of user service platform records in the buffer.
Drawings
Example embodiments will be more fully understood from the detailed description given herein below and the accompanying drawings, in which like elements are represented by like reference numerals, which are given by way of illustration only, and thus do not limit the present disclosure.
FIG. 1 is a block diagram illustrating a portion of an example User Service Platform (USP) network architecture.
Fig. 2 provides a general architecture and functionality suitable for implementing the functional elements described herein or a portion of the functional elements described herein.
FIG. 3 is a flow chart illustrating an example embodiment of a method for generating and transmitting USP records.
FIG. 4A is a flow chart illustrating an example embodiment of a method for receiving and processing USP records.
FIG. 4B is a flow chart illustrating an example embodiment of a method of processing the payload of a buffered USP record.
FIG. 5 is a flow diagram illustrating an example embodiment of a method for processing payload portions to generate payload segments and USP records.
FIG. 6 illustrates a USP record structure according to an example embodiment.
It should be noted that these drawings are intended to illustrate the general nature of methods, structures, and/or materials utilized in certain exemplary embodiments, and to supplement the written description provided below. The drawings, however, are not to scale and may not accurately reflect the precise structural or performance characteristics of any given embodiment, and should not be construed as defining or limiting the scope of values or characteristics encompassed by example embodiments. The use of like or identical reference numbers in the various figures is intended to indicate the presence of like or identical elements or features.
Detailed Description
Various example embodiments will now be described more fully with reference to the accompanying drawings, in which some example embodiments are shown.
Detailed illustrative embodiments are disclosed herein. However, specific structural and functional details disclosed herein are merely representative for purposes of describing example embodiments. Example embodiments may, however, be embodied in many alternate forms and should not be construed as limited to only the embodiments set forth herein.
Accordingly, while example embodiments are capable of various modifications and alternative forms, embodiments are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that there is no intention to limit example embodiments to the specific forms disclosed. Rather, the exemplary embodiments are to cover all modifications, equivalents, and alternatives falling within the scope of the present disclosure. Like reference numerals refer to like elements throughout the description of the figures.
Although one or more example embodiments will be described from the perspective of a controller, agent, or other suitable electronic device, it should be understood that one or more of the example embodiments discussed herein may be executed by one or more processors (or processing circuits) on a suitable device.
FIG. 1 is a block diagram illustrating a portion of an example User Service Platform (USP) network architecture.
As shown in FIG. 1, a portion of the USP network architecture includes a
Although fig. 1 illustrates only a
The
Example controllers include a network service provider controller (ACS), an application service provider controller, and a smartphone controller (e.g., internal or external to a home network). However, example embodiments should not be limited to these examples. Example agents include smart home gateways, smarttvs, and the like.
The proxy service element represents a service functionality exposed by the proxy and may be represented by one or more objects. Examples of proxy service elements include home automation devices such as lights, locks, thermostats, and the like.
Still referring to FIG. 1, the
The USP message refers to the content of USP layer communication, including a message header and a message body. The message body may include, for example, a request, a response, or an error. The message header may include elements that provide information about the message, such as endpoint identifiers for the sender and recipient, the message type, and a message identification (message ID) element. The message ID is an identifier used to associate a response or error with a request.
Although the network shown in fig. 1 includes a proxy mechanism in the form of
Controllers, agents, and/or proxies (such as the controller, agent, and/or proxy illustrated in fig. 1) can be deployed in various configurations, wherein the controller and agent communicate across the internet (or service provider network) or within a local network (e.g., within a home). Regardless of the deployment configuration, when the controller and the proxy exchange USP messages via the USP protocol, the exchange of USP messages may require the use of various MTPs for transmission across the network.
The MTP is located at a layer below the USP protocol that carries messages between an originating USP endpoint (also referred to as originating USP endpoint device, originating endpoint device, etc.) and a receiving USP endpoint (also referred to as receiving USP endpoint device, receiving endpoint device). The originating and receiving USP endpoints may also be collectively referred to as electronic devices. Examples of MTPs include STOMP, CoAP, HyperText transfer protocol (HTTP), and extensible Messaging and Presence protocol (XMPP).
In a more complex deployment, an originating USP endpoint (e.g., controller 102) may transmit USP messages to a receiving USP endpoint (e.g., proxy 106) across one or more MTP proxies that forward USP messages between endpoints using different MTPs.
In fig. 1, for example, the
A USP record is defined as a transport layer payload that encapsulates a sequence of datagrams making up (or representing) a USP message into the payload portion of the USP record. The USP record also provides additional metadata to support the secure and reliable delivery of individual segments (also called fragments) of the USP message. This additional metadata will be discussed in more detail later with respect to fig. 6.
To inhibit the possibility that transmission of USP records is blocked and/or dropped, one or more example embodiments provide the ability to segment and reassemble an unencrypted, encoded, or encrypted payload representing a USP message (e.g., including a USP message or multiple entities (e.g., Transport Layer Security (TLS) entities), the size of the payload being greater than the minimum Maximum Transmission Unit (MTU) of one or more MTPs between an originating USP endpoint and a receiving USP endpoint.
Segmentation and reassembly (SAR) may be employed independently or in conjunction with known security and reliability E2E message exchanges. For example, larger unencrypted USP messages may be exchanged in a more reliable manner using SAR functionality, while smaller USP messages may still maintain the same reliability if SAR functionality is not employed.
At least some example embodiments provide methods for transmitting USP messages in which an originating USP endpoint segments a payload representing a USP message into segments of M bytes, where M may be the size of the smallest MTU from among MTPs (for MTP traversal between the originating USP endpoint and a receiving USP endpoint). In an example where a MTU is associated with STOMP, M may be 225 bytes. After receiving all of the fragments of the fragmented payload, the receiving USP endpoint reassembles the payload fragments to recover the original payload representing the USP message included therein.
FIG. 6 illustrates an example structure of a USP record.
Referring to FIG. 6, a USP record may include: a version; originating USP endpoint identifier (from _ id); session context identifier (session _ id); datagram sequence identifier (sequence _ id); expected sequence identifier (expected _ id); payload encoding information (payload _ encoding); payload encryption information (payload _ encryption); payload segmentation and reassembly (SAR) state (payload _ SAR _ state); payload records SAR status (payload _ rec _ SAR _ state); a payload; and a retransmission identifier (retransmission _ id). As discussed herein, the payload may be referred to as the payload portion of the USP record, which represents the USP message. The remaining metadata portion of the USP record may be referred to as the non-payload portion of the USP record. Although discussed herein as including each field shown in FIG. 6, a USP record need not include all of the non-payload portions shown in FIG. 6. Furthermore, USP records do not require payload to be carried, at least in some cases.
Still referring to FIG. 6, the version indicates the version of the USP record. from _ id identifies the originating USP endpoint that has generated and transmitted the USP record. session _ id includes information identifying the E2E session context (session context) established between the originating USP endpoint and the receiving USP endpoint.
A session context is established between two USP endpoints by sending a USP record with a value that is not currently associated with a USP endpoint combination. In the USP, the proxy initiates the process of establishing a session context between USP endpoints and uniquely identifies the session context within the proxy through a combination of the value of the session _ id and the USP identifier of the associated controller.
The session context may have a lifetime and may expire after a given (or alternatively, a desired or predetermined) time period expires. The expiration of the session context may be controlled by a session context expiration (SessionContextExpiration) parameter at the proxy, where the proxy considers the session context to have expired if the proxy does not see activity (e.g., exchange of USP records) within the session context within a given period of time.
Once a session context is established between USP endpoints, USP records are created to exchange payloads (and USP messages) within the session context. USP records are uniquely identified by their from _ id, session _ id, and sequence _ id.
Still referring to FIG. 6, for the first USP record in a sequence of USP records transmitted in a session context, the sequence _ id may be initialized to zero and incremented after each USP record in the sequence is transmitted. According to at least some example embodiments, an endpoint may maintain a separate value for sequence _ id based on the number of records sent.
The expected _ id indicates the next sequence identifier that the originating USP endpoint wishes to receive from the receiving USP endpoint. The reception of the sequence _ id matching the Expected _ id implicitly confirms the reception of the transport datagram having a sequence _ id smaller than the Expected _ id.
The payload portion of the USP record representing the USP message may include one or more payload records. USP messages may be unencrypted, encrypted using Compact Binary Object Representation (CBOR) object signing and encryption (COSE), or encrypted using Transport Layer Security (TLS) encryption. However, example embodiments should not be limited to these examples. In examples where the USP message is a larger unencrypted USP message (or a USP message encrypted with COSE), the payload portion may include a payload record representing the USP message. In another example, the payload portion may include a plurality of entities (e.g., TLS records), where each entity (e.g., TLS record) constitutes a payload record.
Still referring to fig. 6, the payload _ encoding includes an identification of the encoding protocol used to encode (and decode) the unencrypted payload. The payload value of the payload encoding information includes an uncoded ('0') and a coded ('1').
payload _ encryption includes security protocols (e.g., COSE, TLS, etc.) that are used to encrypt USP messages to generate payload portions.
payload _ sar _ state indicates the fragmentation and reassembly status for the payload at the originating USP endpoint. Example values for payload _ sar _ state include "no segmentation" (e.g., '0'), "start" (e.g., '1'), "in process" (e.g., '2'), and "complete" ('3').
payload _ rec _ sar _ state indicates the fragmentation and reassembly state recorded for a given payload within the payload. Example values of payload _ rec _ sar _ state include "unused" (e.g., '0'), "start" (e.g., '1'), "in process" (e.g., '2'), and "complete" (e.g., '3').
As discussed herein, payload _ sar _ state and payload _ rec _ sar _ state may be collectively referred to as segmentation and reassembly status information (or segmentation and reassembly status indicator information). The payload SAR state (payload _ SAR _ state) may be referred to herein as a payload segmentation and reassembly state, and may indicate the state of the segmentation of the payload at the originating endpoint device when a given payload segment is generated. The payload record SAR state (payload _ rec _ SAR _ state) may be referred to as a payload record segment and reassembly state, and may indicate the state of the segments of the payload record at the originating endpoint device when a given payload segment is generated.
The transmit _ id includes a request for retransmission of the USP record for reliable message exchange. The transmit _ id is included or set when a retransmission is requested.
FIG. 3 is a flow chart illustrating an example embodiment of a method for generating and transmitting USP records.
For purposes of example, the example embodiment shown in FIG. 3 will be described with respect to a session context established between the controller 102 (acting as an originating USP endpoint) and the proxy 106 (acting as a receiving USP endpoint). However, it should be understood that example embodiments should not be limited to this example.
Referring to FIG. 3, at step S300, the
As described above, according to one or more example embodiments, the payload portion representing a USP message may include one or more payload records. For example, the payload portion may include a payload record including an unencrypted USP message, a COSE encrypted payload record, or a plurality of payload records, each payload record including a TLS encrypted entity. However, example embodiments should not be limited to these examples.
Returning to FIG. 3, in step S302, the
If the estimated size of the USP record at step S302 is less than or equal to the minimum MTU of the MTPs (e.g., STOMP and CoAP) between the
Returning to step S302, if the estimated size of the USP record is greater than the minimum MTU of the MTP between the
Also in step S308, the
A more detailed discussion regarding the application of the SAR function and the generation of the USP recording sequence at step S308 will be provided later in fig. 5.
Returning to FIG. 3, in step S310, the
FIG. 5 is a flow diagram illustrating an example embodiment of a method for processing a payload portion to generate a payload segment and then generating a USP record for transmission. Like fig. 3, for exemplary purposes, the example embodiment shown in fig. 5 will be described with respect to a session context established between the
Referring to FIG. 5, at step S502, the
In step S504, the
In step S506, the
If the
In step S516, the
If the
Returning to step S516, if the
For each USP record, when a payload segment included in the USP record is created, a payload SAR state and a payload record SAR state may be set based on the segment state of the payload portion. For example, a first USP record for a first payload segment comprising a payload portion may have a payload SAR state of "start", while a USP record for a last payload segment comprising a payload portion may have a payload SAR state of "complete". The payload SAR state of one or more USP records including a payload segment between the first payload segment and the last payload segment may be "in process".
Similarly, a USP record including a payload segment corresponding to a first portion of the segmented payload record may have a payload record SAR state of "start", and a USP record including a payload segment corresponding to a last portion of the segmented payload record may have a payload record SAR state of "complete". The payload records of one or more USP records that include a payload segment corresponding to the portion of the payload record of the segment between the first portion and the last portion may have a SAR state of "in process".
More specific examples of setting the payload SAR state and the payload recording SAR state will be discussed later.
Returning to step S506 in fig. 5, if the
In step S510, the
Fig. 5 will now be described for a more specific example where the non-payload portion NP is 25 bytes, the original payload portion P is 700 bytes, and the minimum MTU is 225 bytes. In this example, the payload portion P comprises a sequence of two payload records, including a first payload record PR _1 of 200 bytes and a second payload record PR _2 of 500 bytes. In this example, each of the payload records may include a TLS entity, and the TLS entity represents a USP message. However, example embodiments should not be limited to this example.
Referring again to fig. 5, at step S502, the
At step S504, the
In this example, the
Since the payload transfer buffer includes the second payload record PR _2 to be processed (step S516), the
Because the estimated size of the USP records including the second payload record PR _2(500 bytes) and the non-payload portion NP (25 bytes) is greater than the minimum MTU (step S506), the
The
In this example, since there are no other payload records to process for the current payload portion (step S516), the
Also in step S518, the
In this example, for the first USP record in the sequence USPR1 (including payload segment PR1_ SEG1), the payload SAR state (payload _ SAR _ state) is set to "start" and the payload SAR state payload _ rec _ SAR _ state is set to "unused". For the second USP record in the sequence, USPR2 (comprising payload segment PR2_ SEG1), the payload SAR state is set to "in process" and the payload record SAR state is set to "start". For the third USP record in the sequence, USPR3 (comprising payload segment PR2_ SEG2), the payload SAR state is set to "in process" and the payload record SAR state is set to "in process". For the fourth USP record in the sequence USPR4 (comprising payload segment PR2_ SEG3), the payload SAR state is set to "complete" and the payload record SAR state is set to "complete".
The USP records USPR1, USPR2, USPR3, and USPR4 are then stored in the outgoing USP record transfer buffer at step S310 of FIG. 3 for ordered transfer to the
Through the process illustrated in FIG. 5, the
At the
FIG. 4A is a flow diagram illustrating an example embodiment of a method for processing a received USP record of payload segments including segmented payload portions. For purposes of example, the example embodiment shown in fig. 4A will again be described with respect to a session context established between the
Referring to fig. 4A, in response to receiving a USP record having a payload SAR state (payload _ SAR _ state) set to "start" at step S42, the
At step S45, the
At step S46, if neither the payload SAR status nor the payload record SAR status for the next received USP record is set to "complete" (at least one of the payload SAR status and the payload record SAR status for the next received USP record is set to "start" or in process "), then the process returns to step S44, at step S44, to store the next received USP record in the received USP record buffer. The process then proceeds as described herein.
Returning to step S46, if both the payload SAR status and the payload record SAR status for the next received USP record are set to "complete," then in step S47 the proxy 106 stores the next received USP record in the received USP record buffer.
The
In step S410, the
FIG. 4A will now be discussed in more detail with respect to the example given above, in which USP records USPR1, USPR2, USPR3, and USPR4 are sent in order by the
Referring to fig. 4A, upon receiving the first USP record USPR1 having the payload SAR status set to "start" (step S42), the
Then, the
Then, the
Then, the
The
FIG. 4B is a flowchart illustrating an example embodiment of a method of processing buffered USP records in step S48 of FIG. 4A.
Referring to FIG. 4B, in step S482, the
If the payload record SAR status of the current USP record is not set to "unused" at step S483 or not set to "complete" at step S484, the
If the SAR status for the payload record of the current USP record is set to "complete" in step S484, the
In step S4810, the
If the payload SAR status for the most recently processed USP record in the sequence is not set to "complete," the process proceeds to step S4816 and continues as described above.
Returning to step S4810, if the payload SAR status of the most recently processed USP record in the sequence is set to "complete," the process proceeds to step S410 in fig. 4A, where the reassembled payload portion (the payload record stored in the payload record buffer) is processed (e.g., decoded and/or decrypted as necessary) to recover the original USP message.
Returning now to step S483 in fig. 4B, if the payload record SAR of the first USP record in the buffer is set to "unused", the
Fig. 4A, 4B will now be discussed in more detail with respect to the example given above, in which USP records USPR1, USPR2, USPR3 and USPR4 are sent in order by the
Referring to fig. 4B, the
Since the payload record SAR status for the USP record USPR1 is set to "unused" (step S483), the
Since the payload SAR status for the first USP record USPR1 is set to "start" instead of "complete" (step S4810), the
Because the payload record SAR status for the second USP record USPR2 is set to "start", rather than "unused" (step S483) or "complete" (step S484), the
Because the payload record SAR status for the USP record USPR3 is set to "in process", rather than "unused" (step S483) or "complete" (step S484), the
Since the payload record SAR status for the USP record USPR4 is set to "complete" (step S484), the
Then, the
Still referring to FIG. 4B, since the payload SAR status of USPR4 is also set to "complete" for USP recording, the process proceeds to step S410 of FIG. 4A, where the reassembled payload portion P of payload records PR _1 and PR _2 included in the payload recording buffer is processed (e.g., decoded and/or decrypted as needed) in step S410.
FIG. 2 depicts a high-level block diagram of a computer, computing or electronic device suitable for implementing, among other things, originating and receiving USP endpoints (e.g., proxies and controllers), and gateways, MTP proxies and gateways, etc.
Referring to fig. 2,
The
Although discussed herein with respect to an example in which the
Although the example embodiments herein are discussed primarily with respect to a USP message represented by a payload portion at an originating USP endpoint, followed by a message recovered at a receiving USP endpoint, the example embodiments should not be limited to this example. Rather, the payload portion may include and/or carry any originating payload information (e.g., TLS records required for TLS handshaking, etc.).
Although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of the present disclosure. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.
When an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may be present. In contrast, when an element is referred to as being "directly connected" or "directly coupled" to another element, there are no intervening elements present. Other words used to describe the relationship between elements (e.g., "between," directly between, "" adjacent "directly adjacent," etc.) should be interpreted in a similar manner.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises," "comprising," "includes" and/or "including," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
It should also be noted that, in some alternative implementations, the noted functionality/acts may occur out of the order noted in the figures. For example, two figures shown in succession may, in fact, be executed substantially concurrently, or the figures may sometimes be executed in the reverse order, depending upon the functionality/acts involved.
In the following description, specific details are provided to provide a thorough understanding of example embodiments. However, it will be understood by those of ordinary skill in the art that the example embodiments may be practiced without these specific details. For example, systems may be shown in block diagrams in order not to obscure the example embodiments in unnecessary detail. In other instances, well-known processes, structures and techniques may be shown without unnecessary detail in order to avoid obscuring example embodiments.
As discussed herein, the illustrative embodiments will be described with reference to acts and symbolic representations of operations (e.g., in the form of flow diagrams, dataflow diagrams, structure diagrams, block diagrams, etc.) that may be implemented as program modules or functional processes including routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types and that may be implemented using existing hardware, for example, on existing endpoints, clients, gateways, nodes, proxies, controllers, computers, cloud-based servers, web servers, proxies or proxy servers, application servers, etc. As discussed later, such existing hardware may include, among other things: in particular, one or more Central Processing Units (CPUs), system on a chip (SOC) devices, Digital Signal Processors (DSPs), application specific integrated circuits, Field Programmable Gate Arrays (FPGAs) computers, and the like.
Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel, concurrently, or simultaneously. In addition, the order of the operations may be rearranged. A process may terminate upon completion of its operations, but may also have other steps not included in the figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or the main function.
As disclosed herein, the terms "storage medium," "computer-readable storage medium," or "non-transitory computer-readable storage medium" may represent one or more devices for storing data, including Read Only Memory (ROM), Random Access Memory (RAM), magnetic RAM, core memory, magnetic disk storage media, optical storage media, flash memory devices, and/or other tangible machine-readable media for storing information. The term "computer-readable medium" can include, but is not limited to portable or fixed storage devices, optical storage devices, and various other media capable of storing, containing, or carrying instruction(s) and/or data.
Furthermore, example embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine or computer readable medium such as a computer readable storage medium. When implemented in software, the one or more processors will perform the necessary tasks.
A code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
The terms including and/or having, as used herein, are defined as comprising (i.e., open language). The term "coupled," as used herein, is defined as connected, although not necessarily directly, and not necessarily mechanically. Terms derived from the word "indicate" (e.g., "indicates" and "indication") are intended to encompass all of the various techniques that may be used to communicate or reference the indicated object/information. Some, but not all examples of indicated available technologies that may be used to transfer or reference objects/information include: the communication of the indicated object/information, the communication of an identifier of the indicated object/information, the communication of the indicated information for generating the object/information, the communication of some portion or portion of the indicated object/information, the communication of some derivation of the indicated object/information, the communication of some symbol representing the indicated object/information.
According to example embodiments, a client, gateway, node, proxy controller, computer, cloud-based server, web server, application server, proxy or proxy server, etc. may be (or include) hardware, firmware, hardware executing software, or any combination thereof. Such hardware may include one or more Central Processing Units (CPUs), system-on-a-chip (SOC) devices, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and the like, configured as special-purpose machines to perform the functions described herein, as well as any other well-known functions for these elements. In at least some instances, CPUs, SOCs, DSPs, ASICs and FPGAs can be generally referred to as processing circuits, processors and/or microprocessors.
Endpoints, clients, gateways, nodes, proxies, controllers, computers, cloud-based servers, network servers, application servers, proxies or proxy servers, and the like can also include various interfaces including one or more transmitters/receivers connected to one or more antennas, computer readable media, and (optionally) a display device. The one or more interfaces may be configured to transmit/receive (wired and/or wirelessly) data or control signals to/from one or more network elements (such as switches, gateways, end nodes, controllers, servers, clients, etc.) over respective data and control planes or interfaces.
Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments of the present invention. The benefits, advantages, solutions to problems, and any element(s) that may cause or result in such benefits, advantages, or solutions, or cause such benefits, advantages, or solutions to become more pronounced, however, are not to be construed as a critical, required, or essential feature or element of any or all the claims.
Reference will now be made in detail to the embodiments, examples of which are illustrated in the accompanying drawings, wherein like reference numerals refer to like elements throughout. In this regard, example embodiments may have different forms and should not be construed as limited to the description set forth herein. Accordingly, the exemplary embodiments are described below to explain the exemplary embodiments of the present specification by referring to the figures only. Aspects of the various embodiments are specified in the claims.
- 上一篇:一种医用注射器针头装配设备
- 下一篇:一种数据采集系统、传输转换电路以及移动平台