WO2017023302A1 - System and method for delivery of unicast content in hybrid networks - Google Patents

System and method for delivery of unicast content in hybrid networks Download PDF

Info

Publication number
WO2017023302A1
WO2017023302A1 PCT/US2015/043651 US2015043651W WO2017023302A1 WO 2017023302 A1 WO2017023302 A1 WO 2017023302A1 US 2015043651 W US2015043651 W US 2015043651W WO 2017023302 A1 WO2017023302 A1 WO 2017023302A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
multicast
unicast packets
multicast group
plurality
packet
Prior art date
Application number
PCT/US2015/043651
Other languages
French (fr)
Inventor
Sudhanshu Gaur
Brian Litzinger
Original Assignee
Hitachi, Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations contains provisionally no documents
    • H04L12/18Arrangements for providing special services to substations contains provisionally no documents for broadcast or conference, e.g. multicast
    • H04L12/185Arrangements for providing special services to substations contains provisionally no documents for broadcast or conference, e.g. multicast with management of multicast group membership

Abstract

Example implementations described herein are directed to systems and methods to reduce traffic in a network by first identifying groups of user devices that are receiving the same content in the downlink and have similar transport channel conditions. Systems and methods perform intelligent multicasting. In this manner, the systems and methods may possibly reduce network traffic without sacrificing performance and hence, the reduction in congestion and higher capacity is achieved.

Description

SYSTEM AND METHOD FOR DELIVERY OF UNICAST CONTENT IN

HYBRID NETWORKS

BACKGROUND

Field

[0001] The present disclosure is related to communication systems, and more specifically, to delivery of unicasl content in hybrid networks.

Related Art

[0002] Telecommunication network traffic volume is on the rise due to a larger number of subscribers engaging in ever increasing bandwidth-hungry applications. This increased telecommunication network traffic volume can lead to congestion and can reduce the quality of experience for everyone on a network. Related art methods of congestion control such as traffic shaping have been insufficient in addressing the increased use of bandwidth hungry applications.

[0003] An example of the related art unicast based communication system architecture is illustrated in FIG. 1(a). Unicast TCP/UDP based sessions are provided between the content and the end user device. In an example scenario as illustrated in FIG. 1(b), if multiple devices receive the same content (for e.g. an email with a large attachment being sent to multiple users in an office) this same content is transmitted multiple times from the source to each end user device. Such a situation may lead to excessive usage (e.g., wastage) of bandwidth and other network resources.

[0004] In related art implementations directed to multicast architectures, multicast solutions have been applied to improve network utilization. Such related art implementations may involve sending acknowledgments to a multicast packet in a round robin fashion, a block acknowledgement packet to multicast packet, or selectively replicating packets in a semi-probabilistic manner. However, such architectures differentiate between unicast packets and multicast packets, and handle the packets only based on the underlying protocol of the packet. SUMMARY

[0005] Example implementations described herein can be applied to address (e.g., reduce) congestion by multicasting. In example implementations, multiple unicast streams are substituted with a single multicast stream. Example implementations apply the substitution such that there may be substantially no loss of performance at the end user.

[0006] Example implementations can include a Unicast to Multicast converter (UMC) that identifies User Equipment (UE) whose unicast streams can be converted into a single multicast stream and transmits the multicast stream. Example implementations apply the UMC to different access networks such as WiFi, Ethernet and cellular. Further, example implementations described herein illustrate how the UMC node may be deployed at different network segments such as close to the source or close to the access node, as well; as functional details about how a UMC node may be realized.

[0007] Aspects of the present disclosure include an apparatus, which may further include a memory configured to store information for one or more associated user equipment (UE); and a processor, configured to determine a multicast group from the one or more associated UEs based on a plurality of selected unicast packets, wherein each of the plurality of the selected unicast packets have identical payloads; generate a multicast packet for the identified multicast group, the multicast packet also including the identical payload; and transmit the multicast packet to the identified multicast group.

[0008] Aspects of the present disclosure may further include a method, which may involve managing information for one or more associated user equipment (UE); determining a multicast group from the one or more associated UEs based on a plurality of selected unicast packets, wherein each of the plurality of the selected unicast packets have identical payloads; generating a multicast packet for the identified multicast group, the multicast packet also including the identical payload; and transmitting the multicast packet to the identified multicast group.

[0009] Aspects of the present disclosure may further include a computer program, storing instructions for a process, which can include managing information for one or more associated user equipment (UE); determining a multicast group from the one or more associated UEs based on a plurality of selected unicast packets, wherein each of the plurality of the selected unicast packets have identical payloads; generating a multicast packet for the identified multicast group, the multicast packet also including the identical payload; and transmitting the multicast packet to the identified multicast group. The computer program may be stored in a non-transitory computer readable medium.

BRIEF DESCRIPTION OF DRAWINGS

[0010] FIG. 1(a) illustrates an example unicast based communication system architecture.

[0011] FIG. 1(b) illustrates an example scenario within the unicast based communication system architecture.

[0012] FIG. 2 illustrates a high level architecture for multicasting in accordance with an example implementation.

[0013] FIG. 3 illustrates a UMC architecture as applied at the WiFi access point (AP), in accordance with an example implementation.

[0014] FIG. 4 illustrates a multicast architecture for Ethernet with the UMC near the Ethernet Controller, in accordance with an example implementation.

[0015] FIG. 5 illustrates a multicast architecture for Cellular with the UMC near the Base Station, in accordance with an example implementation.

[0016] FIG. 6 illustrates a multicast architecture for WiFi with UMC near the source, in accordance with an example implementation.

[0017] FIG. 7 illustrates a multicast architecture for Ethernet with UMC near the source, in accordance with an example implementation.

[0018] FIG. 8 illustrates a multicast architecture for Cellular with UMC near the source, in accordance with an example implementation. [0019] FIG. 9 shows an example of how a UMC module may map the unicast packets carrying multicast content into different multicast groups, in accordance with an example implementation.

[0020] FIG. 10 illustrates another example of multicast group formation for packets with same payload content but intended for users on different last mile networks, in accordance with an example implementation.

[0021] FIG. 11 shows another differentiating factor used by the UMC for determining multicast groups, in accordance with an example implementation.

[0022] FIG. 12 illustrates how a multicast packet is created from a group of unicast packets with same payload content, in accordance with an example implementation.

[0023] FIG. 13 illustrates a flow diagram for the UMC, in accordance with an example implementation.

[0024] FIG. 14 illustrates an example software architecture of a UMC, in accordance with an example implementation.

[0025] FIG. 15 illustrates an example flow diagram for a UMC agent that checks the source of the incoming multicast packets, in accordance with an example implementation.

[0026] FIG. 16 illustrates an example user equipment upon which example implementations can be implemented.

[0027] FIG. 17 illustrates an example apparatus upon which example implementations can be implemented.

DETAILED DESCRIPTION

[0028] The following detailed description provides further details of the figures and example implementations of the present application. Reference numerals and descriptions of redundant elements between figures are omitted for clarity. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term "automatic" may involve fully automatic or semi-automatic implementations involving user or operator control over certain aspects of the implementation, depending on the desired implementation of one of ordinary skill in the art practicing implementations of the present application.

[0029] FIG. 2 illustrates a high level architecture for multicasting in accordance with an example implementation. In FIG. 2, a source 200, such as a file transfer protocol (FTP) server, video server, or Voice over Internet Protocol (VoIP) server provides content for distribution, which is processed by a UMC 201. The UMC 201 determines the transmission of the content to gateways 202-1 , 202-2, and 202-3 based on the destined user device and also based on the user devices receiving the transmission. For content destined to a group of user devices, the content can be converted to a multicast transmission and can be transmitted to the corresponding group of user devices, including but not limited to transmission to user devices directly (e.g. user device 206-1, 206-2), or to a network for distribution such as a mobile network 204 managing user devices 206-3, 206-4, and 206-5, or a wireless local area network (LAN) 205 managing user devices 206- 6, and 206-7. The transmission can be acknowledged with an acknowledgment packet 207 that is transmitted back to the UMC.

[0030] FIG. 2 illustrates a high level architecture of how network traffic may be addressed (e.g., reduced) by multicasting. In FIG. 2, the network logical entity UMC 201 detects the unicast transmissions that should take place to each end user device and decides if some of these unicast streams can be collapsed into a single multicast stream. The feedback from the end user devices to the UMC facilitates this decision making. The architecture of FIG. 2 applies to various types of access networks such as cellular, Ethernet and WiFi, but not limited thereto, and other access networks may be substituted therefor, as would be understood by those skilled in the art.

[0031] In contrast to related art multicasting applications such as internet protocol television (IPTV), according to the example implementations, the architecture involves unicast applications and determine if and how, further reduction in traffic is obtainable via converting some of these unicast streams into a multicast stream. For example, in the example implementation of office email applications wherein each end user receives the same email with a large attachment (e.g., over a threshold sent by an administrator), such an application would not involve a related art multicasting framework due to the unicast applications, but can be addressed by example implementations of the present disclosure.

[0032] FIG. 3 illustrates a UMC architecture as applied at the WiFi access point (AP), in accordance with an example implementation. Multicasting is performed for the over the air transmission of WiFi signals and reduces only the wireless traffic. The UMC 201-1 is implemented at the AP so that content to be transmitted over the wireless LAN 205 is forwarded to the associated user devices 206-6 and 206-7 in either a unicast or multicast form. In cases where the UMC 201-1 can determine that the received unicast content can be consolidated into a multicast transmission, the UMC 201-1 consolidates the unicast transmission into multicast, and transmits to the associated user devices 206-6 and 206-7 in multicast format.

[0033] FIG. 4 illustrates a multicast architecture for Ethernet with the UMC near the Ethernet Controller, in accordance with an example implementation. The UMC 201-2 can be implemented as an Ethernet controller configured to manage communications over the Ethernet 401 for associated user devices 206-1 and 206-2. Thus, when content is transmitted over the internet 300 to the UMC 201-2, the UMC 201-2 can merge unicast transmission into multicast for content directed at the user devices 206-1 and 206-2 associated with Ethernet 401.

[0034] FIG. S illustrates a multicast architecture for Cellular with the UMC near the Base Station, in accordance with an example implementation. The UMC 201-3 can be implemented at the base station or as an external hardware element connected to the radio access network (RAN). The base station manages the user devices 206-8 and 206-9 associated with the base station over the RAN. When content is transmitted over the internet and carried to the UMC 201-3 through the packet core network 301-1, the UMC 201-3 can merge unicast transmission into multicast for content directed at the user devices 206-8 and 206-9 associated with the base station and RAN 500.

[0035] FIG. 6 illustrates a multicast architecture for WiFi with UMC near the source, in accordance with an example implementation. The UMC can be implemented at the source evolved packet core node (EPC) that is transmitting the packets from the internet, as part of the web server delivering content to the enterprise network, or otherwise placed near or at the source of the packets, depending on the desired implementation. In FIG. 6, the UMC node 201-4 is near the source 200 and transmits content over the internet 300. Here multicasting is done at the IP packet level and reduces IP network and wireless access network traffic. Content to be transmitted over the wireless LAN 205 is provided to the associated user devices 206-6 and 206-7 in a unicast form or a multicast form.

[0036] FIG. 7 illustrates a multicast architecture for Ethernet with UMC near the source, in accordance with an example implementation. In FIG. 7, the UMC node 201-5 is near the source 200 and transmits content over the internet 300. Here, multicasting is done in a manner similar to FIG. 6, wherein content to be transmitted over Ethernet 401 is forwarded to the associated user devices 206-1 and 206-2 in a unicast or multicast form.

[0037] FIG. 8 illustrates a multicast architecture for Cellular with UMC near the source, in accordance with an example implementation. The UMC 201-6 is near the source 200 and transmits content over the internet 301-1 through the packet core network. The base station manages the user devices 206-8 and 206-9 associated with the base station over the RAN. Multicasting is done in a manner substantially similar to FIG. 6, wherein content is transmitted by the base station and RAN 500 to associated user devices 206-8 and 206-9 in a unicast or multicast form.

[0038] FIG. 9 shows an example of how a UMC module may map the unicast packets carrying multicast content into different multicast groups, in accordance with an example implementation. In the example of FIG. 9, all packets are intended for users on same network, wherein packets with the same payload content are mapped to a new multicast packet. In the presented example, three packets 900 on the leftmost side carry the same payload content, followed by two other packets 901 carrying same payload and the last packet (Destination = F) carrying a different payload. Thus in FIG. 9, a total of six packets is shown to carry three different payload contents. These packets are processed by the UMC 201 which creates a new multicast packet for each group of packets carrying the same content, and transmits the multicast packet to the corresponding multicast groups 902 and 903. The last unicast packet remains unchanged.

[0039] FIG. 10 illustrates another example of multicast group formation for packets with same payload content but intended for users on different last mile networks, in accordance with an example implementation. In the example of FIG. 10, all of the packets have the same payload content. Further, packets with destinations on the same last mile network are mapped to a new multicast packet. In this example, all packets carry the same payload content but are still clustered into two different groups based upon two different last mile network for the intended users. In this example, packets 1000 are destined for users on the WiFi network, and packets 1001 are destined for users on the mobile network. Packets 1000 are then transmitted as a multicast packet to the multicast group for subscribers on the WiFi Network 1002. Packets 1001 are transmitted as a multicast packet to the multicast group for subscribers on the mobile network 1003.Thus, the UMC creates two new multicast packets. These packets may employ unequal error protection techniques such as forward-error-correction (FEC), transmission bit-rates, or other error protection techniques as would be understood by those skilled in the art.

[0040] FIG. 11 shows another differentiating factor used by the UMC for determining multicast groups, in accordance with an example implementation. In the example of FIG. 11, all packets have the same payload content and are on the same last mile network. Further, packets intended for users with similar packet error rates (PER) are mapped to a new multicast packet. In this example, all five packets carry the same payload content and are intended for users on the same last mile network. For example, but not by way of limitation, packets 1100 have a PER ~ 10%, while packets 1101 have a PER ~ 1%. When the UMC generates the multicast packets, packets 1100 are consolidated into a multicast packet designated for the multicast group having subscribers with PER ~ 10% 1102. Packets 1101 are consolidated into a multicast packet designated for the multicast group having subscribers with PER ~ \% 1103.

[0041] Thus, the UMC forms different multicast packets based on the packet error rates for the intended users. These packets may employ unequal error protection techniques such as forward-error-correction (FEC), transmission bit-rates etc. The user devices can thereby be grouped based on the PER within a particular threshold. Such a threshold for the grouping based on PER can be set based on the desired implementation in accordance to any desired method known to one of ordinary skill in the art. [0042] FIG. 12 illustrates how a multicast packet is created from a group of unicast packets with same payload content, in accordance with an example implementation. Unicast packets 1200 include a packet header and payload content. The packet header may have information such as the source address indicating the source of the content and the destination address for the user device. In this example, unicast packets having the same payload content, but different destination addresses are consolidated into a multicast packet 1201, which includes the address for the UMC, and the multicast group address for a multicast transmission. The multicast group includes the user devices associated with the destination addresses of the unicast packets 1200.

[0043] FIG. 13 illustrates a flow diagram for the UMC, in accordance with an example implementation. At 1300, the UMC waits to receive incoming packets from a source node within a time window T. At 1301, the UMC forms one or more groups (Gl, G2, and so on) of packets, with the same payload content and the same last mile destination network.

At 1302, the UMC further classifies the packets into subgroups (Gil, G12 G21,

G22, ..) for each group, based on packet error rates, signal to noise ratio (SNR), and other metrics, depending on the desired implementation. At 1303, the UMC checks to determine if there are any subgroups with only one packet. If so (e.g., YES), then the flow proceeds to 1304, wherein the UMC relays the packets belonging to these subgroups to the next node in the network. Otherwise (e.g., NO) the flow proceeds directly to 1305.

[0044] At 130S, the UMC checks to determine if any subgroups include multiple packets. If not (NO), then the flow reverts back to 1300, otherwise (YES), then the flow proceeds to 1306.

[0045] At 1306, for each of the subgroups with multiple packets, the UMC sets ACKRequired = TRUE as a flag if these packets require acknowledgement. Otherwise, the UMC sets ACKRequired = FALSE if the packets do not require acknowledgement.

[0046] At 1307, the UMC creates a multicast packet with the same payload as the original packets in the subgroup for each subgroup receiving a multicast packet. The UMC can also discard the original packets after generating the multicast packet. [0047] At 1308, the UMC sends the multicast data indicator message to the intended users so that they can prepare to receive subsequent multicast transmissions sent by the UMC. At 1309, the UMC starts transmitting the multicast packets to the intended users based on the underlying architecture as illustrated in FIGS. 3 to 8. At 1310, the UMC determines if acknowledgement is required based on the flag set at 1306. If not (NO), the flow proceeds to 1300, otherwise (YES), then the flow proceeds to 1311 to wait for the acknowledgment as illustrated at 207 in FIG. 2. At 1311, the UMC waits for receipt of acknowledgement packets. At 1312, the UMC determines if all of the acknowledgement packets are received. If so (YES), then the flow proceeds to 1314 wherein the UMC sends the acknowledgement packets to the source node. Otherwise (NO), the UMC proceeds to 1313 to transmit the failed multicast packets again.

[0048] As illustrated in FIG. 13, the UMC first determines users that are receiving the same content and then groups them based on their last mile network as well as similarity in access channel conditions. The rationale behind this is that for unicast transmissions, users with similar access channel conditions will have a greater likelihood of seeing the same overall transport channel errors and same trend in their ACK/NACK feedbacks. Thus, one multicast stream may be sent to these users. A special multicast ID can be used for the transmission to the end users. The ACKs sent by the user devices also correspond to unicast ACKs. The UMC can determine retransmission of the multicast stream based on these ACK feedbacks.

[0049] FIG. 14 illustrates an example software architecture of a UMC, in accordance with an example implementation. In FIG. 14, the UMC can include a communication interface 1400 configured to communicate with the source node. ACK handler 1401 is configured to process acknowledgements received from user devices receiving the targeted multicast packet. PER Collection/Computation 1402 is configured to calculate or obtain the PER for one or more user devices as illustrated, for example, in FIG. 11. Multicast content director 1403 receives the packets and determines if the unicast packets can be consolidated into a multicast packet as illustrated in FIGS. 8 to 11. Multicast group formation 1404 is configured to form one or more multicast groups as illustrated in FIG. 11. Multicast routing table 1405 can contain information regarding the multicast groups formed by the UMC. Table 1 as illustrated below, illustrates an example multicast routing table 1404 which summarizes the outcome of the multicast group formation 1404.

Table 1 Information table showing clustering of users into multicast groups

Figure imgf000012_0001

[0050] Multicast packet creation 1406 is configured to consolidate the unicasl packets into multicast packets based on the results from the multicast content detector 1403 and the multicast group formation 1404. Communication interface 1407 is configured to interact with devices that can be configured as UMC agents configured to receive the multicast transmissions, whereupon the agents can utilize the multicast transmission or forward it to the associated user devices.

[0051] FIG. 15 illustrates an example flow diagram for a UMC agent that checks the source of the incoming multicast packets, in accordance with an example implementation. If the packets originate from the UMC (e.g., based on the source address), the UMC agent may choose to respond with ACK packets if so desired. At 1500, the UMC agent waits for the incoming multicast indicator message from the UMC containing information about the multicast group ID. At 1501, the UMC agent receives the multicast indicator message and starts preparing to receive multicast transmissions from the UMC. At 1502, the UMC agent sends out multicast join request containing the multicast group ID to the nearest communication node. At 1503, the UMC agent waits to receive multicast packets for the said multicast group ID. At 1504, the UMC agent determines if the packet is a multicast packet sent by the UMC. If so (YES), then the flow proceeds to 1505, otherwise (NO), the packet is processed as needed at 1507. At 1505, the UMC agent determines if the packet requires an acknowledgement feedback. If so (YES), then the flow proceeds to 1506 to send the acknowledgement to the UMC, otherwise (NO) the flow proceeds to 1507 to process the packet as required.

[0052] FIG. 16 illustrates an example user equipment upon which example implementations can be implemented. The UE 1600 may involve the following modules: the CPU module 1601, the communication interface 1602, and the memory 1603. The CPU module 1601 can be configured to facilitate functionality for the UE as a UMC agent and provide acknowledgement packets as illustrated in FIG. 15. The communication interface 1602 can be implemented as an interface to communicate with the UMC (e.g., a Tx/RX array including an array of one or more antennas to communicate with the one or more base stations functioning as a UMC). The memory 1603 can be configured to receive unicast or multicast packets. Other variations of the UMC agent are also possible depending on the desired implementation. For example, user equipment can be in the form of a mobile device, a laptop computer, or can be a dedicated server or other device to facilitate functionality as a UMC agent to associated user devices.

[0053] FIG. 17 illustrates an example apparatus upon which example implementations can be implemented. Apparatus 1700 may include a memory 1701, a central processing unit (CPU) 1702, storage 1703 and Network interface (I/F) 1704, which can facilitate the functionality of the software architecture as illustrated in FIG. 14. Storage 1703 may be utilized to manage one or more computer programs, which can be loaded into memory 1701 and executed by CPU 1702 to facilitate the function of the UMC. Storage 1703 may also manage information regarding associated user equipment as illustrated in Table 1, which can be loaded into memory for generating the multicast groups.

[0054] In example implementations, CPU 1702 may be loaded with computer programs or instructions from storage 1703 to perform the functions of determining a multicast group from the one or more associated UEs based on a plurality of selected unicast packets, wherein each of the plurality of the selected unicast packets have identical payloads as illustrated in FIG. 12, generating a multicast packet for the identified multicast group, the multicast packet including the identical payload as illustrated in FIG. 12 and transmit the multicast packet to the identified multicast group based on the underlying architectures as illustrated in FIGS. 2 to 8. [0055] CPU 1702 may execute computer programs to facilitate the functionality of the flow diagrams as described herein, for example, in FIG. 13. CPU 1702 may also perform the functions of selecting the plurality of the selected unicast packets by determining, from a plurality of received unicast packets, ones of the plurality of received unicast packets having the identical payloads and having a same destination network as illustrated in FIG. 9 to 12; and determining the multicast group from the one or more UEs associated with the same destination network based on the information stored in the memory as illustrated in Table 1. The determination can also involve having the CPU 1702 select ones of the plurality of the received unicast packets having a substantially similar packet error rate within a threshold for one or more user devices indicated as a destination of the received unicast packets as illustrated in FIG. 11, and by determining the multicast group by determining destination UEs from header information of the selected unicast packets and forming a multicast group from the determined destination UE as illustrated in FIG. 12. CPU 1702 may also generate the multicast packet by generating header information to include source address information indicative of the apparatus, and multicast group identifier information associated with the multicast group as illustrated in FIG. 12 with the UMC address and multicast group address, respectively, and based on Table 1 with the multicast group ID.

[0056] Depending on the desired underlying architecture as illustrated in FIGS. 3 to 8, Apparatus 1700 may be in the form of a standalone devices such as a computer or a server to facilitate the functionality and communicate with user devices through network I/F 1704 based on the underlying architecture (e.g., via internet, via packet core network, etc.), or can be incorporated directly into the controlling apparatus of the underlying architecture, such as an evolved packet core, base station (e.g., macro, pico, etc.), wireless or wired access point, switch or router, Ethernet controller and so on, depending on the desired implementation.

[0057] Finally, some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the essence of their innovations to others skilled in the art. An algorithm is a series of defined steps leading to a desired end state or result. In example implementations, the steps carried out require physical manipulations of tangible quantities for achieving a tangible result.

[0058] Unless specifically stated otherwise, as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing," "computing," "calculating," "determining," "displaying," or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other information storage, transmission or display devices.

[00S9] Example implementations may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer readable medium, such as a computer-readable storage medium or a computer-readable signal medium.

[0060] A computer-readable storage medium may involve tangible mediums such as, but not limited to optical disks, magnetic disks, read-only memories, random access memories, solid state devices and drives, or any other types of tangible or non-transitory media suitable for storing electronic information. A computer readable signal medium may include mediums such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Computer programs can involve pure software implementations that involve instructions that perform the operations of the desired implementation.

[0061] Various general-purpose systems may be used with programs and modules in accordance with the examples herein, or it may prove convenient to construct a more specialized apparatus to perform desired method steps. In addition, the example implementations are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the example implementations as described herein. The instructions of the programming language(s) may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers.

[0062] As is known in the art, the operations described above can be performed by hardware, software, or some combination of software and hardware. Various aspects of the example implementations may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software), which if executed by a processor, would cause the processor to perform a method to carry out implementations of the present application. Further, some example implementations of the present application may be performed solely in hardware, whereas other example implementations may be performed solely in software. Moreover, the various functions described can be performed in a single unit, or can be spread across a number of components in any number of ways. When performed by software, the methods may be executed by a processor, such as a general purpose computer, based on instructions stored on a computer-readable medium. If desired, the instructions can be stored on the medium in a compressed and/or encrypted format.

[0063] Moreover, other implementations of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the teachings of the present application. Various aspects and/or components of the described example implementations may be used singly or in any combination. It is intended that the specification and example implementations be considered as examples only, with the true scope and spirit of the present application being indicated by the following claims.

Claims

CLAIMS What is claimed is:
1. An apparatus, comprising: a memory configured to store information for one or more associated user equipment (IJE); and a processor, configured to: determine a multicast group from the one or more associated UEs based on a plurality of selected unicast packets, wherein each of the plurality of the selected unicast packets have identical payloads; generate a multicast packet for the determined multicast group, the multicast packet comprising the identical payload; and transmit the multicast packet to the determined multicast group.
2. The apparatus of claim 1, wherein the processor is further configured to: select the plurality of the selected unicast packets by determining, from a plurality of received unicast packets, ones of the plurality of received unicast packets having the identical payloads and having a same destination network; and determine the multicast group from the one or more UEs associated with the same destination network based on the information stored in the memory.
3. The apparatus of claim 2, wherein the processor is further configured to select the plurality of the selected unicast packets by selecting ones of the plurality of the received unicast packets having a similar packet error rate within a threshold for one or more user devices indicated as a destination of the received unicast packets.
4. The apparatus of claim 3, wherein the processor is further configured to determine the multicast group by determining destination UEs from header information of the selected unicast packets and forming a multicast group from the determined destination UEs.
5. The apparatus of claim 4, wherein the processor is configured to generate the multicast packet by generating header information comprising source address information indicative of the apparatus, and multicast group identifier information associated with the multicast group.
6. A method, comprising: managing information for one or more associated user equipment (UE); and determining a multicast group from the one or more associated UEs based on a plurality of selected unicast packets, wherein each of the plurality of the selected unicast packets have identical payloads; generating a multicast packet for the determined multicast group, the multicast packet comprising the identical payload; and transmitting the multicast packet to the determined multicast group.
7. The method of claim 6, further comprising: selecting the plurality of the selected unicast packets by determining, from a plurality of received unicast packets, ones of the plurality of received unicast packets having the identical payloads and having a same destination network; and determining the multicast group from the one or more UEs associated with the same destination network based on the information stored in the memory.
8. The method of claim 7, wherein the selecting the plurality of the selected unicast packets comprises selecting ones of the plurality of the received unicast packets having a similar packet error rate within a threshold for one or more user devices indicated as a destination of the received unicast packets.
9. The method of claim 8, wherein the determining the multicast group comprises determining destination UEs from header information of the selected unicast packets and forming a multicast group from the determined destination UEs.
10. The method of claim 9, wherein the generating the multicast packet comprises generating header information comprising source address information indicative of an apparatus generating the multicast packet, and multicast group identifier information associated with the multicast group.
11. A computer program, storing instructions for a process, comprising: managing information for one or more associated user equipment (UE); and determining a multicast group from the one or more associated UEs based on a plurality of selected unicast packets, wherein each of the plurality of the selected unicast packets have identical payloads; generating a multicast packet for the determined multicast group, the multicast packet comprising the identical payload; and transmitting the multicast packet to the determined multicast group.
12. The computer program of claim 11, wherein the instructions further comprise: selecting the plurality of the selected unicast packets by determining, from a plurality of received unicast packets, ones of the plurality of received unicast packets having the identical payloads and having a same destination network; and determining the multicast group from the one or more UEs associated with the same destination network based on the information stored in the memory.
13. The computer program of claim 12, wherein the selecting the plurality of the selected unicast packets comprises selecting ones of the plurality of the received unicast packets having a similar packet error rate within a threshold for one or more user devices indicated as a destination of the received unicast packets.
14. The computer program of claim 13, wherein the determining the multicast group comprises determining destination UEs from header information of the selected unicast packets and forming a multicast group from the determined destination UEs.
15. The computer program of claim 14, wherein the generating the multicast packet comprises generating header information comprising source address information indicative of an apparatus generating the multicast packet, and multicast group identifier information associated with the multicast group.
PCT/US2015/043651 2015-08-04 2015-08-04 System and method for delivery of unicast content in hybrid networks WO2017023302A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2015/043651 WO2017023302A1 (en) 2015-08-04 2015-08-04 System and method for delivery of unicast content in hybrid networks

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2015/043651 WO2017023302A1 (en) 2015-08-04 2015-08-04 System and method for delivery of unicast content in hybrid networks

Publications (1)

Publication Number Publication Date
WO2017023302A1 true true WO2017023302A1 (en) 2017-02-09

Family

ID=57943914

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/043651 WO2017023302A1 (en) 2015-08-04 2015-08-04 System and method for delivery of unicast content in hybrid networks

Country Status (1)

Country Link
WO (1) WO2017023302A1 (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030225845A1 (en) * 2002-05-28 2003-12-04 Samsung Electronics Co., Ltd. Method of providing multicast service and server employing the method
US20060153179A1 (en) * 2004-12-28 2006-07-13 Michael Ho Techniques for transmitting and receiving traffic over advanced switching compatible switch fabrics
US20140146816A1 (en) * 2010-10-05 2014-05-29 Cisco Technology, Inc. System and method for providing smart grid communications and management
US20140177511A1 (en) * 2004-11-05 2014-06-26 Ruckus Wireless, Inc. Unicast to multicast conversion
US8780706B1 (en) * 2012-01-04 2014-07-15 Cisco Technology, Inc. Controlled distribution of Phasor measurement data using multicast routing

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030225845A1 (en) * 2002-05-28 2003-12-04 Samsung Electronics Co., Ltd. Method of providing multicast service and server employing the method
US20140177511A1 (en) * 2004-11-05 2014-06-26 Ruckus Wireless, Inc. Unicast to multicast conversion
US20060153179A1 (en) * 2004-12-28 2006-07-13 Michael Ho Techniques for transmitting and receiving traffic over advanced switching compatible switch fabrics
US20140146816A1 (en) * 2010-10-05 2014-05-29 Cisco Technology, Inc. System and method for providing smart grid communications and management
US8780706B1 (en) * 2012-01-04 2014-07-15 Cisco Technology, Inc. Controlled distribution of Phasor measurement data using multicast routing

Similar Documents

Publication Publication Date Title
US20070127372A1 (en) Digital object routing
US20040179475A1 (en) Apparatus and method for transmitting packets in a communication system
US20100054123A1 (en) Method and device for hign utilization and efficient flow control over networks with long transmission latency
US20130195106A1 (en) Multi-Path Data Transfer Using Network Coding
US20140310388A1 (en) System and Method for Providing a Software Defined Protocol Stack
WO2012033593A1 (en) Packet-data network and methods for ran-agnostic multimedia content distribution
US20120084616A1 (en) Block acknowledgement with retransmission policy differentiation
US20120188873A1 (en) Communication system, communication method, receiving apparatus, and transmitting apparatus
US20120005369A1 (en) System and method of tcp tunneling
US20070097205A1 (en) Video transmission over wireless networks
JP2006025408A (en) Efficient one-to-many content distribution in peer-to-peer computer network
US20140036893A1 (en) System and Method for Enforcing Uplink Wireless Medium Usage in Wireless Networks
US20120079065A1 (en) Data packet transfer over wide area network in fast and reliable manner
Zhou et al. Goodput improvement for multipath TCP by congestion window adaptation in multi-radio devices
WO2014044333A1 (en) Traffic shaping and steering for a multipath transmission control protocol connection
US7729328B2 (en) Real-time sessions for wireless mesh networks
Liu et al. TCP performance in wireless access with adaptive modulation and coding
US8189476B1 (en) Dynamic trunk distribution on egress
Dreibholz et al. Transmission scheduling optimizations for concurrent multipath transfer
Lee et al. IRMA: a reliable multicast architecture for the Internet
US20140198643A1 (en) Wirespeed tcp session optimization for networks having radio segments
US20150222562A1 (en) System and method for efficient frame aggregation
Yilmaz et al. Throughput analysis of non-renegable selective acknowledgments (NR-SACKs) for SCTP
US20150124625A1 (en) Ad-hoc on-demand routing through central control
US20150215236A1 (en) Method and apparatus for locality sensitive hash-based load balancing

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15900569

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15900569

Country of ref document: EP

Kind code of ref document: A1