Generally, the present disclosure is directed to utilization of Per Packet Value (PPV) information for receiving and transmitting data.
Per Packet Value (PPV) is a new method for resource sharing. Specifically, PPV can be considered a per packet marking based bandwidth sharing control method. The basic concept of PPV is that, at a network edge node, each packet gets a marking that indicates a respective importance of the packet. In a bottleneck node these importance values are used in making bandwidth sharing decisions. Packets of a flow can have different importance values. For example, in case of congestion, packets with lowest importance will be dropped first.
PPV based methods were previously proposed to control bandwidth sharing among flows even when per flow queuing was not possible. Both concepts are based on per packet marking based bandwidth sharing control. Algorithms are defined for a single buffer, which results shared delay among these flows. Notably, in some discussions, PPV is also referred to as advanced Drop Precedence (a-DP).
Implementation of PPV in real network scenarios requires solving the placement of PPV information in the packet header fields. Specifically, units of data (e.g., packets, frames, etc.) come in various formats (e.g., ethernet, IPv4, etc.), and can store such data in various ways.
Ethernet uses a so-called EtherType-encoded frame format.
Section 4 of RFC6864 also defines the relevant IPv4 header field values for the atomic datagrams, which reads:
RFC791 defines The DF is the Don't Fragment bit and the MF is the More Fragment bit. A portion of page 12 of RFC791, which defines various control flags and corresponding layouts, is reproduced below:
Various Control Flags.
In IPv6 as defined in [RFC8200], optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the upper-layer header in a packet. There is a small number of such extension headers, each one identified by a distinct Next Header value. IPv6 Extension Headers have the following format:
Extension headers, which can include the Hop-by-Hop Options header and the Destination Options header, as an example, carry a variable number of “options” that are Type-Length-Value (TLV) encoded in the following format:
The Hop-by-Hop Options header [RFC8200] is used to carry optional information that must be examined by every node along a packet's delivery path. The Hop-by-Hop Options header is identified by a Next Header value of 0 in the IPv6 header. The hop-by hop extension header carries a variable number of “options” that are TLV encoded.
The Destination Options header is used to carry optional information that need be examined only by a packet's destination node(s). The Destination Options header is identified by a Next Header value of 60 in the immediately preceding header.
In some embodiments, a method performed by a receiving node for supporting Per Packet Value (PPV) encoding in a packet/frame communicated in a cellular communications system is proposed. The method includes receiving a packet/frame comprising PPV information from a transmitting node, wherein the PPV information indicates a level of importance of the packet/frame determined based on a marking policy of the transmitting node, wherein the packet/frame comprises (a) an Ethernet packet, (b) an IPv4 packet, (c) an IPv6 packet, (d) a Multi-Protocol Label Switching (MPLS) packet, or (e) a multilayer packet descriptive of one or more of (a)-(d). The method includes processing the PPV information in the received packet/frame when the receiving node is configured to handle the PPV information.
In some embodiments, ignoring the PPV information in the received packet/frame when the receiving node is not configured to handle the PPV information.
In some embodiments, receiving the packet/frame comprising the PPV information comprises receiving an Ethernet packet comprising the PPV information, wherein the PPV information is encoded in a PPV Tag (PPV-Tag) or a Redundancy Tag (R-Tag) field located in a header of the Ethernet packet.
In some embodiments, the PPV information comprises (a) end-host PPV information, (b) network PPV information, or (c) both (a) and (b). In some embodiments, the PPV information is encoded in the PPV tag, wherein the PPV tag comprises a first PPV value and a second PPV value, wherein the first PPV value is configured to describe end-host PPV information, and wherein the second PPV is configured to describe network PPV information.
In some embodiments, the PPV information is encoded in the R-Tag, wherein the R-Tag comprises a reserved bitfield, and wherein the reserved bitfield is indicative of whether the R-Tag includes the PPV information.
In some embodiments, receiving the packet/frame comprising the PPV information comprises receiving an IPv4 packet comprising the PPV information, wherein the PPV information is encoded in an Identification (ID) field located in a header of the IPv4 packet.
In some embodiments, the header of the IPv4 packet further comprises a flag field, and wherein at least one bit of the flag field indicates that the IPv4 packet includes PPV information.
In some embodiments, receiving the packet/frame comprising the PPV information comprises receiving an IPv6 packet comprising the PPV information, wherein the PPV information is encoded in a Hop-by-Hop Options header or a Destination Options header of the IPv6 packet.
In some embodiments, receiving the packet/frame comprising the PPV information comprises receiving an MPLS packet comprising the PPV information, wherein the PPV information is encoded in a combination of Extension Label (XL) and Extended Special-Purpose Label (ESPL) located in a label stack of the Ethernet packet.
In some embodiments, receiving the packet/frame comprising the PPV information comprises receiving a multilayer packet descriptive of two or more of the Ethernet packet, the IPv4 packet, the IPv6 packet, and the MPLS packet, wherein the PPV information is encoded in two or more headers respectively associated with the two or more of the Ethernet packet, the IPv4 packet, the IPv6 packet, and the MPLS packet.
In some embodiments, a receiving node for supporting PPV encoding in a packet/frame communicated in a cellular communications system is proposed. The receiving node is adapted to receive a packet/frame comprising PPV information from a transmitting node, wherein the PPV information indicates a level of importance of the packet/frame determined based on a marking policy of the transmitting node, wherein the packet/frame comprises (a) an Ethernet packet, (b) an IPv4 packet, (c) an IPv6 packet, (d) a MPLS packet, or (e) a multilayer packet descriptive of one or more of (a)-(d). The receiving node is adapted to process the PPV information in the received packet/frame when the receiving node is configured to handle the PPV information.
In some embodiments, receiving node for supporting PPV encoding in a packet/frame communicated in a cellular communications system is proposed. The receiving node includes one or more transmitters and one or more receivers. The receiving node includes processing circuitry configured to cause the receiving node to receive a packet/frame comprising PPV information from a transmitting node, wherein the PPV information indicates a level of importance of the packet/frame determined based on a marking policy of the transmitting node, wherein the packet/frame comprises (a) an Ethernet packet, (b) an IPv4 packet, (c) an IPv6 packet, (d) a MPLS packet, or (e) a multilayer packet descriptive of one or more of (a)-(d). The processing circuitry is configured to cause the receiving node to process the PPV information in the received packet/frame when the receiving node is configured to handle the PPV information.
In some embodiments, a method performed by a transmitting node for supporting PPV encoding in a packet/frame communicated in a cellular communications system is proposed. The method includes generating a packet/frame comprising PPV information, wherein the PPV information indicates a level of importance of the packet/frame determined based on a marking policy of the transmitting node, and wherein the packet/frame comprises (a) an Ethernet packet, (b) an IPv4 packet, (c) an IPv6 packet, (d) a MPLS packet, or (e) a multilayer packet descriptive of one or more of (a)-(d). The method includes transmitting the packet/frame comprising the PPV information to a receiving node.
In some embodiments, generating the packet/frame comprising the PPV information comprises generating an Ethernet packet comprising the PPV information, wherein the PPV information is encoded in a PPV-Tag or a R-Tag field located in a header of the Ethernet packet.
In some embodiments, ignoring the PPV information in the received packet/frame when the receiving node is not configured to handle the PPV information.
In some embodiments, receiving the packet/frame comprising the PPV information comprises receiving an Ethernet packet comprising the PPV information, wherein the PPV information is encoded in a PPV Tag (PPV-Tag) or a Redundancy Tag (R-Tag) field located in a header of the Ethernet packet.
In some embodiments, the PPV information comprises (a) end-host PPV information, (b) network PPV information, or (c) both (a) and (b). In some embodiments, the PPV information is encoded in the PPV tag, wherein the PPV tag comprises a first PPV value and a second PPV value, wherein the first PPV value is configured to describe end-host PPV information, and wherein the second PPV is configured to describe network PPV information.
In some embodiments, the PPV information is encoded in the R-Tag, wherein the R-Tag comprises a reserved bitfield, and wherein the reserved bitfield is indicative of whether the R-Tag includes the PPV information.
In some embodiments, receiving the packet/frame comprising the PPV information comprises receiving an IPv4 packet comprising the PPV information, wherein the PPV information is encoded in an ID field located in a header of the IPv4 packet.
In some embodiments, the header of the IPv4 packet further comprises a flag field, and wherein at least one bit of the flag field indicates that the IPv4 packet includes PPV information.
In some embodiments, generating the packet/frame comprising the PPV information comprises generating an IPv6 packet comprising the PPV information, wherein the PPV information is encoded in a Hop-by-Hop Options header or a Destination Options header of the IPv6 packet.
In some embodiments, generating the packet/frame comprising the PPV information comprises generating an MPLS packet comprising the PPV information, wherein the PPV information is encoded in a combination of XL and ESPL located in a label stack of the Ethernet packet
In some embodiments, generating the packet/frame comprising the PPV information comprises generating a multilayer packet descriptive of two or more of the Ethernet packet, the IPv4 packet, the IPv6 packet, and the MPLS packet, wherein the PPV information is encoded in two or more headers respectively associated with the two or more of the Ethernet packet, the IPv4 packet, the IPv6 packet, and the MPLS packet.
In some embodiments, a transmitting node for supporting PPV encoding in a packet/frame communicated in a cellular communications system is proposed. The transmitting node is adapted to generate a packet/frame comprising PPV information, wherein the PPV information indicates a level of importance of the packet/frame determined based on a marking policy of the transmitting node, and wherein the packet/frame comprises (a) an Ethernet packet, (b) an IPv4 packet, (c) an IPv6 packet, (d) a MPLS packet, or (e) a multilayer packet descriptive of one or more of (a)-(d). The transmitting node is adapted to transmit the packet/frame comprising the PPV information to a receiving node.
In some embodiments, a transmitting node for supporting PPV encoding in a packet/frame communicated in a cellular communications system is proposed. The transmitting node includes one or more transmitters and one or more receivers. The transmitting node includes processing circuitry configured to cause the transmitting node to generate a packet/frame comprising PPV information, wherein the PPV information indicates a level of importance of the packet/frame determined based on a marking policy of the transmitting node, and wherein the packet/frame comprises (a) an Ethernet packet, (b) an IPv4 packet, (c) an IPv6 packet, (d) a MPLS packet, or (e) a multilayer packet descriptive of one or more of (a)-(d). The processing circuitry is configured to cause the transmitting node to transmit the packet/frame comprising the PPV information to a receiving node
The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.
The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.
Radio Node: As used herein, a “radio node” is either a radio access node or a wireless communication device.
Radio Access Node: As used herein, a “radio access node” or “radio network node” or “radio access network node” is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station (e.g., a network node that implements a gNB Central Unit (gNB-CU) or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node.
Core Network Node: As used herein, a “core network node” is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.
Communication Device: As used herein, a “communication device” is any type of device that has access to an access network. Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC). The communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless or wireline connection.
Wireless Communication Device: One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (IoT) device. Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC. The wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless connection.
Network Node: As used herein, a “network node” is any node that is either part of the RAN or the core network of a cellular communications network/system.
Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.
Note that, in the description herein, reference may be made to the term “cell”; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.
There currently exist certain challenge(s). Specifically, there is no encapsulation format defined so far to encode Per Packet Value (PPV) in Ethernet, IPv4, IPv6, and Multi-Protocol Label Switching (MPLS) packets/frames.
In general, encapsulation of the PPV information should fulfill the following requirements:
Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. Embodiments disclosed herein are directed to PPV encoding in Ethernet, IPv4, IPv6, and MPLS packet/frame headers.
With respect to Ethernet, the present disclosure uses a PPV containing Tag for Ethernet encapsulated frames. Specifically, two formats of the “PPV containing Tag” are disclosed in the present disclosure.
With respect to IPv4, the present disclosure uses IPv4 header's Identification (ID) field for encoding PPV. A PPV aware Active Queue Management (AQM) device will read the PPV from the ID field and use the value for the forwarding decision (e.g., forward, drop, Explicit Congestion Notification (ECN)-Echo (ECE) mark). PPV unaware AQM devices simply ignore the content of the ID field.
With respect to IPv6, the present disclosure describes how to include and encode PPV in an IPv6 extension header as a PPV option. Specifically, the PPV option can be used as a hop-by-hop option or as a destination option.
With respect to MPLS, the present disclosure uses a special purpose label to encode PPV in MPLS encapsulated packets. Specifically, an explicit format of the “PPV-Label” is defined herein.
In essence, embodiments disclosed herein include a solution to place PPV information in Ethernet, IPv4, IPv6, and MPLS header fields.
Ethernet: a PPV containing Tag for Ethernet encapsulated frames is used. The present disclosure defines two formats of the “PPV containing Tag”.
IPv4: The PPV field is required for real network deployment of the PPV based resource sharing framework. The present disclosure solves this problem on IPv4 networks with the usage of the ID field as the PPV field for atomic datagrams. To distinguish PPV marked IPv4 packets from non-marked packets, the reserved first bit of Flags field can be used. The solution is compatible with the current IPv4 deployments, transparent for non-PPV aware devices.
IPv6: Implementation of PPV based resource sharing in real network scenarios requires to solve the placement of PPV information in the packet header fields. The present disclosure uses the IPv6 Hop-by-Hop or Destination Options header. The present disclosure defines an explicit format of the proposed PPV option.
MPLS: Implementation of PPV based resource sharing in real network scenarios requires to solve the placement of PPV information in the packet header fields. The present disclosure uses a special purpose label to encode PPV in MPLS encapsulated packets. The present disclosure defines an explicit format of the “PPV-Label”.
There are, proposed herein, various embodiments which address one or more of the issues disclosed herein. In one aspect, a method performed by a receiving node for supporting PPV encoding in a packet/frame communicated in a cellular communications system is provided. The method includes receiving a packet/frame (e.g., Ethernet, IPv4, IPv6, and MPLS) comprising a PPV information from a transmitting node. The PPV information indicates a level of importance of the packet/frame determined based on a marking policy of the transmitting node. The method also includes processing the PPV information in the received packet/frame when the receiving node is configured to handle the PPV information.
In another aspect, a method performed by a transmitting node for supporting PPV encoding in a packet/frame communicated in a cellular communications system is provided. The method includes generating a packet/frame (e.g., Ethernet, IPv4, IPv6, and MPLS) comprising a PPV information, wherein the PPV information indicates a level of importance of the packet/frame determined based on a marking policy of the transmitting node. The method also includes transmitting the packet/frame comprising the PPV information to a receiving node.
Certain embodiments may provide one or more of the following technical advantage(s).
The base stations 402 and the low power nodes 406 provide service to wireless communication devices 412-1 through 412-5 in the corresponding cells 404 and 408. The wireless communication devices 412-1 through 412-5 are generally referred to herein collectively as wireless communication devices 412 and individually as wireless communication device 412. In the following description, the wireless communication devices 412 are oftentimes UEs, but the present disclosure is not limited thereto. It should be noted that, although the base stations 402 are discussed as one example of a network node in which aspects of the embodiments described herein may be implemented, the present disclosure is not limited thereto.
Before discussing specific embodiments of the present disclosure, a pair of high-level processes that may be employed by a receiving node (e.g., the base stations 402 in
For example, the packet/frame generated at the transmitting node includes (a) an Ethernet packet, (b) an IPv4 packet, (c) an IPv6 packet, (d) a MPLS packet, or (e) a multilayer packet including one or more of (a)-(d). In one embodiment, the transmitting node can add the PPV information to an Ethernet packet (step 600-1). In another embodiment, the transmitting node can encode the PPV information in an IPv4 packet (step 600-2). In another embodiment, the transmitting node can encode the PPV information in an IPv6 packet (step 600-3). In another embodiment, the transmitting node can encode the PPV information in an MPLS packet (600-4). In another embodiment, the transmitting node can encode the PPV information in a multilayer packet (step 600-5). The multilayer packet may include additional header(s) that describe two or more of the Ethernet packet as encoded in step 600-1, the IPv4 packet as encoded in step 600-2, the IPv6 packet as encoded in step 600-3, and the MPLS packet as encoded in step 600-4. Notably, the PPV information indicates a level of importance of the packet/frame determined based on a marking policy of the transmitting node. The transmitting node is also configured to transmit the packet/frame comprising the PPV information to a receiving node (step 602).
Specific embodiments of the present disclosure with respect to Ethernet, IPv4, IPv6, and MPLS are discussed in detail below.
One embodiment is directed to encoding the PPV in a special Tag, referred herein as a “PPV containing Tag”. In other words, in one embodiment, the packet/frame comprising PPV information generated and transmitted in steps 600 and 602 of
The PPV-Tag defined here is a new Tag. As illustrated in
The value for the EtherType of the PPV-Tag is to be allocated by the Institute of Electrical and Electronics Engineers (IEEE) Registration Authority.
The PPV-Tag may contain two PPV values. PPV1 follows immediately the EtherType. Unused PPV values must be set to zero.
In a non-limiting example, PPV1 and PPV2 (e.g., a first PPV value and a second PPV value) can be used, for example, to ensure PPV transparency mode, where PPV1 is treated as an End Host PPV that includes, or is otherwise configured to describe (e.g., in header(s) that support two values, etc.). End-host PPV information (e.g., representing a PPV value set by a PPV capable end host, etc.) and PPV2 is treated as a Network PPV that includes, or is otherwise configured to describe, network PPV information (e.g., representing a PPV value set by a network domain, etc.).
The Redundancy Tag (R-TAG) is defined in IEEE 802.1CB-2017 to encode sequence number information in Ethernet frames. The R-TAG is 6 octets long and its structure is illustrated in
The R-TAG information consists of two fields:
The first two octets of the R-TAG information is a 16-bit Reserved field. This field shall be transmitted with all zeros and shall be ignored on receipt.
The last two octets of the R-TAG information are a 16-bit value, the Sequence Number field.
As stated in IEEE 802.1CB-2017, future standards can use the most-significant bits of the Reserved field for sub-typing purposes.
As such, in a non-limiting example, the present disclosure proposes to utilize the reserved bitfield of the R-Tag to describe the PPV information. Specifically, the R-Tag carrying PPV can be encoded as follows:
The reserved bitfield of the R-Tag is divided in two fields: (1) sub-type field and (2) protocol version field. Their values refer to the usage of the R-Tag for PPV purposes (e.g., to describe the respective PPV information, etc.). Two PPV versions are distinguished. PPV1 and PPV2 can be used for example to ensure PPV transparency mode, where PPV1 is treated as an End Host PPV (representing a PPV value set by a PPV capable end host) and PPV2 is treated as a Network PPV (representing a PPV value set by a network domain). The 16 bits Sequence Number field of the R-Tag is used to encode the value of the PPV.
Notably, an Ethernet frame may contain multiple R-Tags, which may be necessary in various scenarios, such as the above described PPV transparency case.
Packet processing behavior of the transmitting nodes in the process of
The transmitting node in
The PPV value of the packet is transmitted in the ID field of the IPv4 packet. The DF and the MF flag bits are important for PPV marking as DF and MF flags can be applied on atomic datagrams. The sender or a PPV marking capable intermediate node puts the PPV into the IPv4 header's ID field of atomic datagrams. Methods to ensuring that traffic in the network (using PPV based AQM) contains only atomic datagrams is out-of-scope here.
Using the ID field to encode PPV is allowed since RFC6864 states “Originating sources MAY set the IPv4 ID field of atomic datagrams to any value.” Marking the PPV value in the ID field is compatible with the current networking deployment, since the values of the ID field of atomic datagrams are ignored by the network devices, as so stated in RFC6864 that “All devices that examine IPv4 headers MUST ignore the IPv4 ID field of atomic datagrams.”
In cases when the IP datagram is larger than the Maximum Transmission Unit (MTU) of the destination path, the packet will be dropped because DF=1. As such, the PPV value in the ID field does not have meaning in such cases, thus making it compatible with the current behavior.
For the AQM, it must be possible to distinguish PPV marked and non-marked packets. According to an embodiment disclosed herein, the reserved first bit of Flags field is used as a PPV-bit (i.e., set to “1” to show that the PPV information is included). That makes the PPV marked atomic datagrams easy to recognize and AQM can make the forwarding decision based on the PPV value. As such, the Flags field is utilized to indicate that the IPv4 packet includes PPV information (e.g., a flag of “1”, etc.).
Packet processing behavior of transmitting nodes in
The transmitting node in
In a non-limiting example, it is possible to encode the PPV in the IPv6 Hop-by-Hop Options header or IPv6 destination Options header. An exemplary PPV extension header is provided in
PPV1 and PPV2 can be used, for example, to ensure PPV transparency mode. In this regard, PPV1 is treated as an End Host PPV (representing a PPV value set by a PPV capable end host) and PPV2 is treated as a Network PPV (representing a PPV value set by a network domain).
If a network element is not PPV aware, the network element can ignore the packet header PPV-option based on looking at the first two bits of option type.
Alternatively, the option length can be any multiplier of 2, also indicating how many different PPV values are present.
Packet processing behavior of the transmitting nodes in
The transmitting node in
Historically, The MPLS Label Stack Encoding specification (RFC3032) defined four special-purpose label values (0 to 3) and set aside values 4 through 15 for future use. These labels have special significance in both the control and the data plane. Since then, further values have been allocated (e.g., values 7, 13, and 14). RFC7274 extends the space of special-purpose labels and defines allocation of special purpose MPLS labels.
RFC7274 defines Extension Label (XL) as a label that indicates that an extended special-purpose label follows. Furthermore, RFC7274 defines Extended Special-Purpose Label (ESPL) as a special-purpose label that is placed in the label stack after the Extension Label. The combination of XL and ESPL may be regarded as a new form of “compound label” comprising more than one consecutive entry in the label stack. (Note: XL has a value of 15 and ESPL will be allocated by IANA when PPV Label standardized from range 18-239.)
The PPV-Label disclosed herein conforms to the XL+ESPL combo in the label stack (inline with RFC7274) and contains the PPV information. Specifically, PPV-Label is a label:
PPV-Labels are generated by an ingress Label Switch Router (LSR), based entirely on resource sharing related information. Notably, the PPV-Labels cannot have values in the reserved label space.
In a non-limiting example, PPV-Label is formed as follows:
There can be multiple PPV-Labels in the label stack.
Packet processing behavior of the transmitting nodes in
As used herein, a “virtualized” radio access node is an implementation of the radio access node 1100 in which at least a portion of the functionality of the radio access node 1100 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the radio access node 1100 may include the control system 1102 and/or the one or more radio units 1110, as described above. The control system 1102 may be connected to the radio unit(s) 1110 via, for example, an optical cable or the like. The radio access node 1100 includes one or more processing nodes 1200 coupled to or included as part of a network(s) 1202. If present, the control system 1102 or the radio unit(s) are connected to the processing node(s) 1200 via the network 1202. Each processing node 1200 includes one or more processors 1204 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1206, and a network interface 1208.
In this example, functions 1210 of the radio access node 1100 described herein are implemented at the one or more processing nodes 1200 or distributed across the one or more processing nodes 1200 and the control system 1102 and/or the radio unit(s) 1110 in any desired manner. In some particular embodiments, some or all of the functions 1210 of the radio access node 1100 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 1200. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 1200 and the control system 1102 is used in order to carry out at least some of the desired functions 1210. Notably, in some embodiments, the control system 1102 may not be included, in which case the radio unit(s) 1110 communicates directly with the processing node(s) 1200 via an appropriate network interface(s).
In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of radio access node 1100 or a node (e.g., a processing node 1200) implementing one or more of the functions 1210 of the radio access node 1100 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).
In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the wireless communication device 1400 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).
Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.
While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).
Embodiment 1: a method performed by a receiving node for supporting PPV encoding in a packet/frame communicated in a cellular communications system, the method comprising one or more of: receiving a packet/frame (e.g., Ethernet, IPv4, IPv6, MPLS, and multilayer) comprising a PPV information from a transmitting node, wherein the PPV information indicates a level of importance of the packet/frame determined based on a marking policy of the transmitting node, and processing the PPV information in the received packet/frame when the receiving node is configured to handle the PPV information.
Embodiment 2: the method of embodiment 1, further comprising ignoring the PPV information in the received packet/frame when the receiving node is not configured to handle the PPV information.
Embodiment 3: the method of any one of previous embodiments, wherein receiving the packet/frame comprising the PPV information comprises receiving an Ethernet packet comprising the PPV information, wherein the PPV information is encoded in a PPV-Tag or a R-Tag field located in a header of the Ethernet packet.
Embodiment 4: the method of any one of previous embodiments, wherein receiving the packet/frame comprising the PPV information comprises receiving an IPv4 packet comprising the PPV information, wherein the PPV information is encoded in an ID field located in a header of the IPv4 packet.
Embodiment 5: the method of any one of previous embodiments, wherein receiving the packet/frame comprising the PPV information comprises receiving an IPv6 packet comprising the PPV information, wherein the PPV information is encoded in a Hop-by-Hop Options header or a Destination Options header of the IPv6 packet.
Embodiment 6: the method of any one of previous embodiments, wherein receiving the packet/frame comprising the PPV information comprises receiving an MPLS packet comprising the PPV information, wherein the PPV information is encoded in a combination of XL and ESPL located in a label stack of the Ethernet packet.
Embodiment 6A: the method of embodiments 3 to 6, wherein receiving the packet/frame comprising the PPV information comprises receiving a multilayer packet comprising two or more of the Ethernet packet, the IPv4 packet, the IPv6 packet, and the MPLS packet, wherein the PPV information is encoded in the two or more of the Ethernet packet, the IPv4 packet, the IPv6 packet, and the MPLS packet.
Embodiment 7: a method performed by a transmitting node (410) for supporting PPV encoding in a packet/frame communicated in a cellular communications system, the method comprising one or more of generating a packet/frame (e.g., Ethernet, IPv4, IPv6, MPLS, and multilayer) comprising a PPV information, wherein the PPV information indicates a level of importance of the packet/frame determined based on a marking policy of the transmitting node, and transmitting the packet/frame comprising the PPV information to a receiving node.
Embodiment 8: the method of embodiment 7, wherein generating the packet/frame comprising the PPV information comprises generating an Ethernet packet comprising the PPV information, wherein the PPV information is encoded in a PPV-Tag or a R-Tag field located in a header of the Ethernet packet.
Embodiment 9: the method of any one of previous embodiments, wherein generating the packet/frame comprising the PPV information comprises generating an IPv4 packet comprising the PPV information, wherein the PPV information is encoded in an ID field located in a header of the IPv4 packet.
Embodiment 10: the method of any one of previous embodiments, wherein generating the packet/frame comprising the PPV information comprises generating an IPv6 packet comprising the PPV information, wherein the PPV information is encoded in a Hop-by-Hop Options header or a Destination Options header of the IPv6 packet.
Embodiment 11: the method of any one of previous embodiments, wherein generating the packet/frame comprising the PPV information comprises generating an MPLS packet comprising the PPV information, wherein the PPV information is encoded in a combination of XL and ESPL located in a label stack of the Ethernet packet.
Embodiment 11A: the method of embodiments 8 to 11, wherein generating the packet/frame comprising the PPV information comprises generating a multilayer packet comprising two or more of the Ethernet packet, the IPv4 packet, the IPv6 packet, and the MPLS packet, wherein the PPV information is encoded in the two or more of the Ethernet packet, the IPv4 packet, the IPv6 packet, and the MPLS packet.
Embodiment 12: A radio access node for supporting PPV encoding in a packet/frame communicated in a cellular communications system, the radio access node comprising processing circuitry configured to perform any of the steps of any of the Group A embodiments, and power supply circuitry configured to supply power to the radio access node.
Embodiment 13: A network node for supporting PPV encoding in a packet/frame communicated in a cellular communications system, the network node comprising a processing node configured to perform any of the steps of any of the Group B embodiments.
At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s).
Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.
This application claims the benefit of provisional patent application Ser. No. 63/079,538, filed Sep. 17, 2020, the disclosure of which is hereby incorporated herein by reference in its entirety.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/SE2021/050891 | 9/17/2021 | WO |
Number | Date | Country | |
---|---|---|---|
63079538 | Sep 2020 | US |