WO2012118449A2

WO2012118449A2 - Communication devices and methods for performing communication

Info

Publication number: WO2012118449A2
Application number: PCT/SG2012/000068
Authority: WO
Inventors: Shoukang ZHENG; Haiguang Wang; Choong Hock MAR; Jaya Shankar S/O Pathmasuntharam; Anh Tuan Hoang; Wai Leong YEOW
Original assignee: Agency for Science Technology and Research Singapore
Current assignee: Agency for Science Technology and Research Singapore
Priority date: 2011-03-03
Filing date: 2012-03-02
Publication date: 2012-09-07
Anticipated expiration: 2013-09-03
Also published as: WO2012118449A3

Abstract

An infrastructure station for performing direct local forwarding in a cellular mobile communication system which includes a core network is provided. The infrastructure station includes a transceiver, a detector, a binder, and a forwarder. The detector is configured to detect a local forwarding opportunity between at least two mobile stations under the control of the infrastructure station based on received transmissions. The binder is configured to bind an uplink flow and a downlink flow together into a data flow route between the at least two mobile stations. The uplink flow and the downlink flow are identified by uniquely identifiable station flow identifiers. These station flow identifiers are unique service flow identifiers, a composition of at least a uniquely identifiable station identifier and a uniquely identifiable flow identifier, or connection identifiers. The forwarder is configured to forward received data from the at least two mobile stations by employing a station flow identifier provided in received data transmissions to determine the data route flow.

Description

COMMUNICATION DEVICES AND METHODS FOR PERFORMING

COMMUNICATION

RELATED APPLICATIONS

[0001] The present application claims priority to the following Singapore Patent Applications: 201101537-7 filed on March 3, 2011, and 201108175-9 filed on November 4, 2011, all of which are herein incorporated by reference in their entirety.

FIELD OF THE DISCLOSURE

[0002] Embodiments of the invention generally relate to a communication terminal and a method for performing communication.

BACKGROUND

[0003] The IEEE 802.16η System Requirements Document (SRD) specifies a requirement for High Reliability (HR) network. As such, one of the requirements is for the mobile stations (HR-MSs) to communicate directly with each other in the event of network failure. The HR-MS to HR-MS direct communications scenario could for example occur in the event of a disaster where the backbone network is destroyed. The rescue teams (e.g. firemen and police officers) would have to communicate directly with each other without a backbone network in order to provide disaster recovery.

SUMMARY

[0004] In a first implementation, an infrastructure station for performing direct local forwarding in a cellular mobile communication system which includes a core network is provided. The infrastructure station includes a transceiver, a detector, a binder, and a forwarder. The detector is configured to detect a local forwarding opportunity between at least two mobile stations under the control of the infrastructure station based on received transmissions. The binder is configured to bind an uplink flow and a downlink flow together into a data flow route between the at least two mobile stations. The uplink flow and the downlink flow are identified by uniquely identifiable station flow identifiers. These station flow identifiers are unique service flow identifiers, a composition of at least a uniquely identifiable station identifier and a uniquely identifiable flow identifier or connection identifiers. The forwarder is configured to forward received data from the at least two mobile stations by employing a station flow identifier provided in received data transmissions to determine the data route flow.

[0005] In another implementation, a method for performing direct local forwarding in a cellular mobile communication system which includes a core network is provided. The method includes detecting a local forwarding opportunity between at least two mobile stations under the control of an infrastructure station based on received transmissions, binding an uplink flow and a downlink flow together into a data flow route between the at least two mobile stations, and forwarding received data from the at least two mobile stations by employing the station flow identifier provided in received data transmissions to determine the data route flow. The uplink flow and the downlink flow are identified by uniquely identifiable station flow identifiers. These station flow identifiers are unique service flow identifiers, a composition of at least a uniquely identifiable station identifier and a uniquely identifiable flow identifier, or connection identifiers. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] To further clarify the above and other advantages and features of the present invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof that are illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

[0007] FIG. 1 shows communication flow arrangements according to embodiments.

[0008] FIG. 2 shows a flow diagram according to an embodiment.

[0010] FIGs. 3-4 show message flow diagrams according to embodiments.

[001 1] FIGs. 5-6 show communication flow arrangements according to embodiments.

[0012] FIG. 7 shows a flow diagram according to an embodiment.

[0013] FIG. 8 shows a communication flow arrangement according to an embodiment. [0014] FIGs. 9-10 show message flow diagrams according to embodiments.

DETAILED DESCRIPTION

[0015] Reference will now be made to figures wherein like structures will be provided with like reference designations. It is understood that the drawings are diagrammatic and schematic representations of exemplary embodiments of the invention, and are not limiting of the present invention nor are they necessarily drawn to scale.

[0016] FIG. 1 shows communication flow arrangements according to embodiments. In particular, FIG. 1A shows paths for a 802.16m network without local forwarding, and FIG. IB shows paths for a 802.16η network with local forwarding. The IEEE 802.16 standard family specifies a Media Access Control (MAC) and Physical layer communication protocols for cellular-based wireless communications. The IEEE 802.16 working group has created a new task group, IEEE 802.16η, to investigate a few new features, of which local forwarding is desired. It is desired that a high reliability (HR) network, such as for example 802.16η, be capable of providing local forwarding. Local forwarding is a mechanism that allows one high reliability mobile station (HR-MS) to communicate to one or more HR-MSs via an infrastructure station without going through a backhaul. Infrastructure stations include, for example, high reliability base stations (HR-BS) and high reliability relay stations (HR-RS). It is further desired that a HR- Network be capable of providing optimized MAC protocols for unicast and multicast transmissions to support applications of two-way communications services among a group of HR-MSs. For instance, Push to Talk (PTT) services may be served on such transmission networks and provide audio, video, still images, formatted text, non- formatted text, and file transfer applications. Methods to support BS-initiated local forwarding and RS-initiated local forwarding are provided.

[0017] Two HR-MSs 9, 11 start communication via infrastructure stations HR-RS 7 and HR-BS 5 in FIG. 1A and via HR-RS 7 performing local forwarding in FIG. IB. In FIG. 1 solid lines indicate links between the nodes 5, 7, 9, 11 and the dash lines 1, 2, 3, 4 indicate the communication data paths. When local forwarding can be accomplished by HR-RS 7, as in FIG. IB, the bandwidth of the downlink and uplink from HR-BS 5 to HR- RS 7 for the communication between HR-MS 9 and HR-MS 11 could be conserved to improve the efficiency as compared to FIG. 1A. More specifically, while communication path 1 in FIG. 1A remains unchanged in FIG. IB, communication paths 2, 3, 4 in FIG. 1A are collapsed into communication paths 2, 3 in FIG. IB. Alternatively, communication paths 2, 3, 4, as shown FIG. 1A, may be further collapsed into just communication path 2.

[0018] FIG. 2 shows a flow diagram according to an embodiment. In particular, a method for performing direct local forwarding in a cellular mobile communication system which includes a core network is provided. The method, for instance may implemented with an infrastructure station for performing direct local forwarding in a cellular mobile communication system which includes a core network. The infrastructure station may include a transceiver, a detector, a binder, and a forwarder. The detector is configured to detect 13 a local forwarding opportunity between at least two mobile stations under the control of the infrastructure station based on received transmissions. The binder is configured to bind 15 an uplink flow and a downlink flow together into a data flow route between the at least two mobile stations. The uplink flow and the downlink flow are identified by uniquely identifiable station flow identifiers. These station flow identifiers are unique service flow identifiers (SFIDs), a composition of at least a uniquely identifiable station identifier (STID) and a uniquely identifiable flow identifier (FID) or connection identifiers (CIDs). The forwarder is configured to forward 17 received data from the at least two mobile stations by employing a flow identifier provided in received data transmissions to determine the data route flow.

[0019] FIGs. 3-4 show message flow diagrams according to various embodiments. In one embodiment of local forwarding, both HR-MSs 9, 11 are associated with the same HR-RS 7. Referencing FIG. 3, control messages and data flow of a BS-initiated local forwarding scheme is shown. HR-BS 5 is capable of obtaining and maintaining a table of HR-MS unique identifications (IDs). Such uniquely identifiable station identifiers may, for example, be media access control (MAC) addresses, mobile numbers and/or IP addresses. HR-BS 5 is further capable of obtaining and maintaining in the table uniquely identifiable station flow IDs. A station flow ID may be a SFID, a composition of a STID and a FID or a connection identifier (CID). During network entry and initialization, HR- MSs 9, 11 are assigned IP addresses and station IDs (STIDs) during registration by HR- RS 7 so that HR-BS 5 can obtain the information of mobile station (MS) unique IDs, such as IP addresses or MAC address, and STIDs through the message from HR-RS 7. When HR-MS 9 starts an uplink connection setup request with DSA REQ/DSC REQ control messages for a flow ID (FID), the source and destination IP addresses can be provided in the DSA_REQ/DSC_REQ control messages so that HR-BS 5 can obtain the information to setup the table and the binding if local forwarding is applicable. If the uplink or downlink connection setup after handover is known by HR-BS 5, it should be able to setup the table and the binding as well.

[0020] The detector for detecting a local forwarding opportunity between at least two mobile stations under the control of the infrastructure station based on received transmissions is configured to receive a DSC/DSA-REQ transmission, decode a source and a destination encoded in the transmission, detect that the source and the destination are both under the control of the base station, and respond to the DSC/DSA-REQ and initiate a new DSC/DSA-REQ for local forwarding. As an example, HR-MS 9 sends DSA-REQ 19 to HR-RS 7. HR-RS 7 sends control messages to core networks (ASN) to setup data path (not shown), and sends control messages DSC-REQ 21 (or DSA-REQ) to HR-BS 5 to complete the setup for the uplink flow of HR-MS 9 after HR-RS 7 receives DSA-REQ 19 from HR-MS 9. Once HR-BS 5 receives DSC-REQ 21 from HR-RS 7, HR-BS 5 decodes the information of the destination, HR-MS 11, from DSC-REQ 21 message and detects 23 both HR-MS 9 and HR-MS 11 are under the control of the same relay station, namely HR-RS 7.

[0021 ] HR-BS 5 sends DSC-RSP 25 to HR-RS 7 to indicate that it optionally requests to setup the uplink flow from HR-RS 7 to HR-BS 5 itself. HR-RS 7 also indicates to HR- BS 5 that it can complete the setup of uplink flow from HR-RS 7 to HR-BS 5 if requested by HR-BS 5, replying with DSA-ACK 27.

[0022] HR-BS 5 the proceeds to send control messages DSA-REQ 29 (or DSC-REQ) to HR-RS 7. DSA-REQ 31, or other control messages, can be used to indicate to HR-RS 7 that local forwarding is feasible for the unicast flow. HR-RS 7 sends control message DSA-RSP 31 to the HR-BS 5 and HR-BS 5 replies with DSA-ACK 33. The above control message sent to HR-RS 7 can be used to indicate that there will be local forwarding so that HR-RS 7 can bind two flows together. If HR-RS 7 is permitted to do local forwarding after admission control, HR-RS 7 sends DSA-REQ 35 to HR-MS 11 to indicate a downlink FID will be setup by HR-RS 7. This is followed by the control messages of DSA-RSP 37 from HR-MS 11 to HR-RS 7 and of DSA-ACK 39 from HR- RS 7 to HR-MS 11 to complete the downlink flow setup.

[0023] After the downlink flow is setup, HR-RS 7 sends DSA-RSP 43 to HR-MS 9 and HR-MS 9 replies with DSA-ACK 45 to HR-RS 7 to complete the setup of the uplink flow and HR-RS 7 assigns a FID for HR-MS 9. HR-RS 7 then proceeds to bind the uplink FID from HR-MS 9 to HR-RS 7 and the downlink FID from RS to MS 11 together so that HR-RS 7 is capable of routing data flow from HR-MS 9 to HR-MS 11 without going through HR-BS 5. Thus, HR-MS 9 may send data with the assigned FID to HR-RS 7. HR-RS 7 forwards the received data 49 from HR-MS 9 to HR-MS 11 by employing the newly created binding and may also send data 51, if required, from HR-MS 9 to HR- BS 5.

[0024] Once data transmission is finished, the tear down procedure can proceed. More particularly, HR-MS 9 sends DSD-REQ 53 to HR-RS 7. HR-RS 7 replies with DSD- RSP 55. HR-MS 9 sends DSD-ACK 57 back to HR-RS 7. HR-RS 7 continues by sending DSD-REQ 59 to HR-BS 5, requesting the release of uplink flow and indicating the end of the connection between HR-MS 9 and HR-MS 11. HR-BS 5 replies with DSD- RSP 61 and HR-RS 5 sends DSD-ACK 63 to HR-BS 5. HR-BS 5 deletes the binding of two flows. HR-RS 5 further sends DSD-REQ 65 to HR-MS 11, indicating the end of the connection between HR-MS 9 and HR-MS 11. HR-MS 11 replies with DSD-RSP 67 and HR-RS 5 sends DSD-ACK 69 back to HR-MS 1 1. HR-RS 5 finishes by removing the binding of the uplink flow from HR-MS 9 to HR-RS 7 and the downlink flow from HR- RS 5 to HR-MS 1 1.

[0025] Referencing FIG. 4, control messages and data flow of a RS-initiated local forwarding scheme is shown. Similar to FIG. 3, HR-RS 7 is capable of obtaining and maintaining a table of HR-MS unique identifications (IDs). As discussed above, such uniquely identifiable station identifiers may, for example, be media access control (MAC) addresses, mobile numbers and/or IP addresses. HR-RS 7 is further capable of obtaining and maintaining in the table uniquely identifiable station flow IDs. A station flow ID may be a SFID, a composition of a STID and a FID or a connection identifier (CID). When HR-MS 9 starts an uplink connection setup request with DSA REQ/DSC REQ control messages for a flow ID (FID), the source and destination IP addresses can be provided in the DSA REQ/DSC REQ control messages so that HR-RS 7 can obtain the information to setup the table and the binding if local forwarding is applicable. If the uplink or downlink connection setup after handover is known by HR-RS 7, it should be able to setup the table and the binding as well.

[0026] The detector for detecting a local forwarding opportunity between at least two mobile stations under the control of the infrastructure station based on received transmissions is configured to receive a DSC/DSA-REQ transmission, decode a source and a destination encoded in the transmission, detect that the source and the destination are both under the control of the relay station, transmit a control message to the core network to setup a data path, a new DSC/DSA-REQ for local forwarding, and a query whether to setup an uplink form the relay station to the base station, and receive a DSC/DSA-RSP and initiate a new DSC/DSA-REQ for local forwarding. As an example, HR-MS 9 sends DSA-REQ 19 to HR-RS 7. When HR-RS receives DSA-REQ 19 from HR-MS 9. HR-RS 7 decodes the information of the destination HR-MS 11 from DSA- REQ 19 message and detects that both HR-MS 9 and HR-MS 11 are under the control of the same relay station, namely HR-RS 7.

[0027] HR-RS 7 sends control messages to core networks (ASN) to setup a data path (not shown) and also sends a DSA-REQ 21 (or DSC-REQ) to HR-BS 5, requesting to perform local forwarding for HR-MS 9 and querying HR-BS 5 whether to setup the uplink from HR-RS 7 to HR-BS 5 for the flow. When HR-BS 5 receives DSA-REQ 21 (or DSC-REQ) from HR-RS 7, HR-BS 5 determines whether to allow HR-RS 7 to do local forwarding for HR-MS 9. If HR-BS 5 confirms HR-RS 7 can perform local forwarding, HR-BS 5 by replying with DSA-RSP 25 which also indicates whether HR- RS 7 should setup an uplink flow for HR-BS 5. HR-RS 7 responds with DSA-ACK 27. Once HR-RS 7 has been instructed to perform local forwarding, setting up RS-initiated local forwarding will proceed similar to the BS-initiated local forwarding described with reference to FIG. 3.

[0028] Once data transmission is finished, the tear down procedure can proceed. More particularly, HR-MS 9 sends DSD-REQ 75 to HR-RS 7. HR-RS 7 replies with DSD- RSP 77. HR-MS 9 sends DSD-ACK 79 back to HR-RS 7. HR-RS 5 continues by sending DSD-REQ 81 to HR-MS 11, indicating the end of the connection between HR- MS 9 and HR-MS 11. HR-MS 1 1 replies with DSD-RSP 83 and HR-RS 5 sends DSD- ACK 85 back to HR-MS 11.

[0029] HR-RS 7 continues by sending DSD-REQ 87 to HR-BS 5, requesting the release of uplink flow and indicating the end of the connection between HR-MS 9 and HR-MS 11. HR-BS 5 replies with DSD-RSP 89 and HR-RS 5 sends DSD-ACK 91 to HR-BS 5. HR-BS 5 deletes the binding of two flows. HR-RS 5 finishes by removing the binding of the uplink flow from HR-MS 9 to HR-RS 7 and the downlink flow from HR- RS 5 to HR-MS 11. [0030] The above methods can be extended to multi-hop relay networks, for example an 802.16j network, such that an infrastructure station is configured to forward data from more than one hop away. The source MS will send a DSA-REQ to a BS. The BS will then send a DSA-REQ to the nodes along the path until access is made to a RS for admission control for the source MS. If it is admitted by all the intermediate RSs and the access RS along the path, the access RS replies with a DSA-RSP to the BS. The BS then sends DSA-RSP to the source MS, assigning a flow ID to it, and meanwhile sends DSA- ACK to all the RSs along the path to the source MS. If the pair of MSs for the unicast flow is under the control of the same common upstream RS, the BS can detect this flow can be done by local forwarding by sending DSA-REQ to the access RS for downlink admission control of the destination MS and also sending DSA-REQ to establish the service flow between the access RS and the destination MS. The binding of the two flows for local forwarding is performed at the common upstream RS rather than the access RS, unless the access RS is the common upstream RS. The binding can be instructed by the BS through a DSA-REQ control messages to the common upstream RS that will do local forwarding. Similarly, the BS will send a DSA-REQ to the access RS of the destination MS to check whether it can be admitted, and thus expect the access RS to send a DSA-RSP to itself so that it can reply with a DSA-ACK to complete the service flow setup between BS and access RS. After that the DSA-REQ should be issued by the BS to the destination MS to establish the flow between the access RS and the destination MS.

[0031] In the normal operation of local forwarding, both BS-initiated and RS-initiated methods have to setup the uplink between HR-RS 7 and HR-BS 5 if HR-BS 5 requires a copy of the data from HR-MS 9. In order to save the bandwidth setup for this uplink flow, it is considered whether HR-BS 5 could receive the DL-MAP of HR-RS 7 and arrange to receive downlink frames from HR-RS 7 to HR-MS 1 1. In this case, the bandwidth of the uplink between HR-RS 7 and HR-BS 5 for the local forwarding may be saved and HR-BS 5 may use ARQ to indicate the data receiving. [0032] FIGs. 5-6 show communication flow arrangements according to embodiments. Scenario may arise where data packets of a HR-MS 95 need to be multicasted to a group of HR-MSs 97 under the control of the same HR-RS 7. One possible application of such a scenario is a PTT (Push-To-Talk) service. The data flow for the normal operation of a PTT service is inefficient because of repeated data retransmissions from the HR-RS to PTT server 99 and back again to HR-RS 7. Thus a MAC protocol optimized for PTT service is provided by allowing local forwarding of multicast packets as shown in FIGs. 5-6 such that an infrastructure station further includes a multicaster configured to maintain a table that stores source and destination address pairs for a plurality of downlink connections in a detected multicast packet. The binder is configured to bind a downlink multicast flow, with an uplink unicast flow, and the station flow IDs are service flow IDs, a composition of at least a uniquely identifiable multicast group identifier and a uniquely identifiable flow identifier, or connection IDs .

[0033] A PTT group has a source component HR-MS 95 with an uplink unicast connection 1 provided by HR-BS 5, and a multicast group of k destination MSs HR-MS 97 with a downlink multicast connection 2 provided by HR-BS 5.

[0034] HR-BS 5 can obtain and maintain a table of HR-MS unique IDs and station flow IDs. HR-BS 5 is the coordinator of the local forwarding. Once the service has been created, any changes are accomplished using a DSC-REQ. Once the service is no more needed, it can be deleted using a DSD-REQ. The formation of the PTT group, the request and grant of Right-to-Speak in the PTT group, and any other control signaling between the PTT server and group may be handled by upper layer communications.

[0035] FIG. 7 shows a flow diagram according to an embodiment. HR-BS 5 creates a downlink unicast connection to HR-MS 95 using a DSA message and transmitting the right-to-transmit 101 packet. HR-MS 95 then requests an uplink unicast connection and specifies the source and destination IP address, namely the PTT server, in the MS initiated DSA-REQ 103 message. HR-BS 5 creates a table that stores 107 the source and destination IP addresses pair for each uplink connection. A PTT flag may be included in the DSA-REQ message for the uplink connection so that only the uplink connection that is created as part of the PTT service is stored in the table. After receiving the first data packet from the PTT server. HR-BS 5 identifies 119 that the packet is a multicast packet, specifically a multicast destination with IP addresses. HR-BS 5 uses the source IP address of the IP packet to search for a match of the destination IP address in the table that contains the active uplink connections. The matched IP address is actually the IP address of the PTT server. Further information such as service class may be used to refine the search. If a match is found, it determines whether local forwarding is possible. If local forwarding is possible, the method proceeds in the same fashion as the BS and RS initiated forwarding procedure for unicast local forwarding as described with the following differences.

[0036] In the setup of the downlink connection, a DSA-REQ 123 for the multicast connection is used. The DSA-REQ 123 for the multicast transmission must include: the Multicast Group ID and the FID which are together used to identify the connection. Instead of single packet DSA-REQ, multiple packets DSA-REQs have to be sent to each downlink multicast member. Multiple local forwarding bindings may occur. This is because the multicast members may form subgroups that are dispersed over a few controlling RSs.

[0037] In the normal operation of local forwarding, if either the source HR-MS 9 or the destination HR-MS 11 moves out of the control of the currently serving HR-RS 7 that performs local forwarding, HR-MS 9, 11 or HR-RS 7 may trigger a handover process. Both BS-initiated and RS-initiated methods consider the re-establishment of the connection to handle the handover process. When handover starts, either HR-MS 9 or HR-RS 7 will be triggered and context transfer will be done between serving station and target station. The serving HR-RS (SRS) send control messages to target BS (TBS) or target RS (TRS) (defined as T-ABS/T-ARS in 802.16m) that will serve the HR-MS requiring this handover. Thus, the binding of the flows of uplink and downlink station flow IDs (e.g. FIDs) should be detached in serving HR-RS and HR-BS if the HR-BS also keeps the related information.

[0038] When the source HR-MS 9 performs handover to TBS/TRS, the uplink flow from TRS to its corresponding BS (TBS) should be established in addition to the uplink flow of the source HR-MS 9 to TRS, or the uplink flow of the source HR-MS 9 to TBS if there is no RS between TBS and HR-MS. SRS should remove the uplink flow for this source HR-MS 9. If there is no common upstream HR-RS between SRS and TRS, SRS sends out DSA-REQ to its controlling HR-BS (SBS) to establish the downlink flow from SBS to this SRS for the incoming flow from the source HR-MS 9 that are handover to be under the control of TRS/TBS. If there is a common upstream RS between SRS and TRS, SRS should send out a DSA-REQ to the common upstream HR-RS to establish the downlink flow from this common upstream HR-RS to this SRS for the incoming flow from the source HR-MS 1, which are handed over to be under the control of TRS/TBS. The binding will be transferred to the common upstream RS, which will replace SRS to perform the local forwarding, and the uplink flow of HR-MS 1 is established between HR-MS 1 and this common upstream HR-RS, after the uplink flow is also established between the access RS and the common upstream HR-RS if there are a few hops between them. The binding at serving HR-RS should be removed.

[0039] When the destination HR-MS 1 1 performs handover to TBS/TRS, the uplink flow from SRS to its corresponding SBS should be established if it hasn't been setup by the serving SRS for the case of no common upstream RS between TRS and SRS. If there is a common upstream RS between TRS and SRS, the uplink flow should be established between this common upstream RS and SRS. SRS should remove the downlink flow for this destination HR-MS 11. After handover to TBS/TRS, the downlink flow should be setup for this destination HR-MS 11 to receive the data from the source HR-MS 9. If there is no common upstream RS between SRS and TRS, the downlink flow is established between TBS and TRS. Otherwise, if there is a common upstream RS between SRS and TRS, the downlink flow is established between the common upstream RS and TRS. In this case, the binding will be transferred to this common upstream RS, which will replace SRS to perform the local forwarding.

[0040] In the operation of HR-RS without local forwarding for the flow between two HR-MSs, if either the source HR-MS 9 or the destination HR-MS 11 moves into the control of a HR-RS that will perform local forwarding, both BS-initiated and RS-initiated methods consider the re-establishment of the connection during the handover process.

[0041] When handover starts, either HR-MS or HR-RS will be triggered. The HR-RS controlling the HR-MS without handover informs the RS/BS serving the other HR-MS such that it will handle this handover. Thus, the binding of the flows of uplink and downlink station flow identifier should be established in TRS if both the source HR-MS 9 and destination HR-MS 11 are under the control of same HR-RS, or in the common upstream HR-RS between the source HR-MS 9 and the destination HR-MS 11.

[0042] When the source HR-MS 9 performs handover to TRS, SBS/SRS should remove the uplink flow for this source HR-MS 9 and the uplink flow from TRS to its corresponding BS (TBS) should be established if required by BS in addition to the uplink flow from the source HR-MS 9 to TRS.

[0043] TRS should bind the uplink station flow identifier of HR-MS 9 and downlink station flow identifier of HR-MS 11 together and local forwarding will be done by TRS if there is no common upstream RS between the source HR-MS 1 and the destination HR- MS2. Otherwise the common upstream RS between the source HR-MS 9 and the destination HR-MS 11 should bind the uplink station flow identifier of HR-MS 9 and downlink station flow identifier of HR-MS 11 together and perform the local forwarding for HR-MS 9 and HR-MS 11.

[0044] When the destination HR-MS 11 performs handover to TRS, SBS/SRS should remove the downlink flow for this destination HR-MS2, and the downlink flow from TRS to HR-MS2 should be established. At the same time, if the uplink flow between TRS and its corresponding BS (TBS) hasn't been setup, after handover to TRS, the uplink flow should be setup for TBS to receive the data from the source HR-MS 9 if it requires.

[0045] FIG. 8 shows a communication flow arrangement according to an embodiment. The source HR-MS 95 handover procedure is similar to the unicast cases described since mainly the uplink unicast component is affected.

[0046] The handover of multicast member HR-MS 97 to another TRS or TBS is more complicated and there are three cases. For simplicity in describing the method, it is assumed that there are three multicast sub-groups: a 1st subgroup with kl members, a 2nd subgroup with k2 members, and a 3rd subgroup with k3 members such that kl + k2 + k3 = k. Such assumptions may be generalized and the following may be implemented generally. An HR-MS 97 is assumed to originally belong to kl sub-group and handover to k2 sub-group.

[0047] When kl > 2, k2 > 1 and k3 = k - (kl + k2), the multicast member HR-MS 97 is handed over to a TRS that is also controlling a subgroup of multicast HR-MS 97 as shown in FIG. 8. For such a case after the completion of handover, either HR-MS 97 or HR-BS 5 can initiate the DSA messaging to connect to the downlink multicast service. In case that the sub-groups belong to two different BS, the downlink service will be the Enhanced Multicast Broadcasting Services (E-MBS). The DSA messaging for E-MBS is used instead. Note that in this case, the existing local forwarding binding is not affected.

[0048] When kl = 1, k2 > 1 and k3 = k - (1 + k2), after the handover of the multicast member HR-MS 97 the first sub-group disappeared. If local forwarding existing between the first sub-group and HR-MS 95, then unbinding proceeds. After the HR-MS 97 is handed over to TRS, the DSA procedure then follows as described. [0049] When kl = k, k2 = 0 and k3 = 0, the multicast member HR-MS 97 is handed over to a TRS with no existing sub-group. The existing local forwarding binding between the first sub-group and HR-MS 95, if any, remains unaffected. Once the handover to TRS is done, the same DSA messaging procedure is performed. However for this case, the BS needs to discover whether a local forwarding opportunity exists by searching for the common upstream RS that connects between HR-MS 1 and the handover HR-MS2. The procedure of binding then follows as described.

[0050] When, kl = 1, k2 = 0 and k3 = k - 1, the multicast member HR-MS 97 is handed over to a TRS with no existing sub-group. Originally, the multicast member HR- MS 97 is in the 1st subgroup where there is only a single member. The unbinding procedure is performed if local forwarding exists in the original 1st sub-group. Once the handover to TRS is done, the same DSA messaging procedure is performed. However, the BS needs to discover whether a local forwarding opportunity exists by searching for the common upstream RS that connects between HR-MS 95 and the handover HR-MS 97. The procedure of binding then follows as described.

[0051] Thus, as described above, an infrastructure station may include a handover module configured to a station handover where one of the at least two mobile stations moves out of local forwarding control of the infrastructure station and removes the data flow thereto. Further, the handover module may be configured to detect a station handover where the at least two mobile stations remain under local forwarding control of the infrastructure station and re-establish local forwarding after the station handover.

[0052] Local forwarding (LF) opportunity may be detected by HR-infrastructure station or other manner (e.g. ASN-GW). There are a few approaches to detect the LF opportunity. The following method and protocol specifies control messages for 802.16m but when the detection method and LF protocol is applied to 802.16e, AAI control messages given in the following description for 802.16m shall be replaced by the corresponding messages in 802.16e. In this case the proposed control messages should be renamed accordingly. For example, AAI-LFA-REQ is renamed as LFA-REQ. Moreover, CIDs in 802.16e are used as the station flow identifiers.

[0053] During network entry phase, HR-MS obtains the identification in the related domain (e.g. IPv4 or IPv6 address). HR infrastructure station (e.g. as DHCP relay) is able to obtain this information to maintain a table of one unique STID and one or multiple identifications in the related domain (e.g. IPv4 address) for the HR-MSs.

[0054] In DSA procedure to setup the link with HR infrastructure station by HR-MS, in the related domain, the identification for HR-MS can be obtained (e.g. IPv4/IPv6 address or Ethernet MAC address). There may be multiple identifications for HR-MS in one specific domain. For example, multiple IPv4 addresses are associated with one HR- MS. HR infrastructure station is able to maintain a table of one unique STID and one or multiple identifications in the related domain for the HR-MSs. Although the identification for the concerned domain in DSA is optionally present, the HR infrastructure station (HR-RS) can negotiate with HR-BS during HR-RS network entry to enforce the compulsory presence of identifications for the concerned domain (e.g. IPv4).

[0055] During data forwarding after DSA procedure to setup the links for two HR-MSs to communicate, ASN-GW may be able to detect the LF opportunity if the association of the identifications in a specific domain (such as IPv4 or IPv6) and SFIDs (or indirectly STIDs of both communicating HR-MSs) can be recognized by ASN-GW. In this case, even there is no data flow going to the destination HR-MS before the detection of LF opportunity, ASN-GW is able to determine whether there is an opportunity of LF for two communicating HR-MSs after the data traffic has been forwarded by ASN-GW once through the downlink to the destination HR-MS.

[0056] HR infrastructure station may implement some data path functions to facilitate the detection of LF opportunity, similar to ASN-GW detection. Even if there is no data flow going to the destination HR-MS before the detection of LF opportunity, a HR infrastructure station may be able to determine whether there is an opportunity of LF for two communicating HR-MSs after the data traffic has been forwarded by HR infrastructure station once through the downlink to the destination HR-MS.

[0057] If there is no backhaul, HR infrastructure station (either HR-BS or HR-RS) shall detect the LF. In this case, the above methods without ASN-GW engaging may be used to determine LF opportunity.

[0058] The capability of LF is negotiated and may be enabled during HR-RS network entry. HR-RS sends control message (e.g. AAI-SBC-REQ for 802.16m) to HR-BS, indicating that whether it can determine LF opportunity and/or perform LF. HR-BS replies with control message (e.g. AAI-SBC-RSP) to indicate which shall detect LF opportunity and perform LF. The following element is included into the control message of basic capability request.

[0059] The AAI-SBC-REQ shall include TLVs within the set of Local Forwarding Supported that indicates the HR-BS or HR-RS capabilities, whether local forwarding detection is supported and local forwarding is supported.

[0060] AAI-SBC-REQ Message Field description

[0062] Local 2 ObOO: Local

Forwarding forwarding (LF) is

Capability not supported

[0063] 0b01 : HR-

RS detects LF

opportunity and

performs LF

[0064] 0b 10: HR-

RS does not detect

LF opportunity but

can perform LF

[0065] Obl l:

reserved

}

[0066] The following element is included into the control message of basic capability response.

[0067] AAI-SBC-RSP Message Field description

detects LF

opportunity and HR- RS performs LF as

needed

Ob 10: HR-RS

detects LF

opportunity and HR- RS performs LF as

needed

Obl l : ASN detects

LF opportunity and

HR-RS performs LF

as needed

[0068] When HR-infrastructure station detects the LF opportunity, it may send control message to ASN to get the permission for the forwarding to be done by HR-infrastructure station without going through backhaul. If the ASN detects the opportunity of LF, it communicates with HR-infrastructure station via R6 interface. The details of control messages (e.g. PATH REG REQ/RSP/ACK and RR REQ/RSP/ACK) are out of scope. Upon HR-BS receives the downlink control messages from ASN, it recognizes that it is an HR-RS related after classification and can transfer the control message in AAI-L2- XFER format to HR-RS. On the uplink, HR-RS sends the control message using AAI-L2- XFER message. The control messages of AAI-SBC-REQ/RSP, AAI-LFA- REQ/RSP/ACK and AAI-LFD-REQ/RSP/ACK are sent through AAI-L2-XFER from HR-RS to HR-BS.

[0069] After connection setup control message (AAI-DSA-REQ) sent by the source HR-MS has been received by HR-RS, if LF opportunity is detected and can be done by HR-RS, the control message AAI-LFA-REQ is sent by HR-RS to HR-BS, requesting to setup LF. When HR-BS receives this control message, it sends the control message (AAI- DSA-REQ) to the destination HR-MS for downlink connection establishment. The handshaking is complete with the response (AAI-DSA-RSP) and the acknowledgement (AAI-DSA-ACK) between HR-BS and the destination HR-MS as normal connection as described.

[0070] If the LF is admitted, HR-BS responds to the HR-RS by AAI-LFA-RSP with response code ObOO and valid downlink FID;

[0071] If downlink setup fails, HR-BS sends AAI-LFA-RSP with response code 0b 10 and an empty downlink FID field;

[0072] If LF is not allowed, AAI-LFA-RSP with response code ObOl and an empty downlink FID field indicates LF cannot be done by the requesting HR-RS.

[0073] The HR-RS will reply with AAI-LFA-ACK to HR-BS. HR-RS responds to the source HR-MS with AAI-DSA-RSP, which confirms by AAI-DSA-ACK, following the DSA procedure in 16.2.12.6. In this case, uplink FID is managed by HR-RS per 16.6.2.1.1. HR-BS/HR-RS may use the field of Backup Option in control messages AAI- LFA-REQ/RSP to request or indicate the option, establishing the uplink for the source HR-MS to send data as backup to HR-BS/ASN.

[0074] AAI-LFA-REQ Message Field description

HR-MS or multicast Present

group ID

FID 4 Downlink FID of Present when it is destination HR-MS available or multicast specific

FID that is

associated with

multicast group ID

Backup Option 1 Uplink data backup Present when it is option indicator available ObO: No uplink data

backup

Obi : Uplink data

backup is required

[0076] AAI-LFA-RSP Message Field description

Size

Field Value/Description Conditions

(bits)

Response Code 2 ObOO: OK Shall always

ObOl : Local Present forwarding is not

allowed

Ob 10: Downlink

setup failure

Obi 1 : Reserved

STID 12 STID of source HR- Shall always

MS Present

FID 4 Uplink FID of Shall always source HR-MS Present STID 12 STID of destination Shall always

HR-MS or multicast Present group ID

FID that is

associated with

multicast group ID

Backup Option 1 Uplink data backup Present if sent by option indicator HR-BS

ObO: Uplink data

backup is not

required

Obi: Uplink data

backup is required

[0077] AAI-LFA-ACK Message Field description

Size

Field Value/Description Conditions

(bits)

STID 12 STID of source HR- Shall always

MS Present

FID 4 Uplink FID of Shall always source HR-MS Present

STID 12 STID of destination Shall always

HR-MS or multicast Present group ID

FID 4 Downlink FID of Shall always destination HR-MS Present or multicast specific

FID that is

associated with

multicast group ID

Confirmation Code 1 Zero indicates the Shall always

request was Present

successful. Nonzero

indicates failure

[0078] If HR-BS/ASN rather than HR-RS detects the LF opportunity that can be done through HR-RS, when control message of connection setup (AAI-DSA-REQ) sent by source HR-MS has received by HR-RS, uplink FID is managed by HR-RS and HR-RS communicates with the other network entities using AAI-L2-XFER messages carrying ASN control messages to setup the data path for this FID of the HR-MS. Once LF opportunity is detected and determined by HR-BS/ASN, data path setup shall be deferred for the uplink flow from the source HR-MS.

[0079] If the LF is impossible, HR-RS will communicate with ASN entities to complete data path setup, and the uplink setup is complete after HR-RS sends control message AAI-DSA-RSP and the source HR-MS confirms by control message AAI-DSA- ACK.

[0080] If the LF is determined, HR-BS will continue the downlink setup through control messages AAI-DSA-REQ/ RSP/ACK between HR-BS and the destination HR- MS. When downlink setup is complete, HR-BS sends the control message AAI-LFA- REQ to the HR-RS, requesting the HR-RS to perform LF. When the HR-RS receives this control message and acknowledges the HR-BS with AAI-LFA-RSP that LF will be done by itself, HR-BS confirms by control message AAI-LFA-ACK. If all these procedures are successful, the uplink setup is complete after HR-RS sends AAI-DSA-RSP and HR-MS confirms by AAI-DSA-ACK. In this case, if the field of Backup Option is set in LFA procedure (AAI-LFA-REQ/RSP/ACK), the data path for the uplink flow may be setup. Otherwise, data path may be setup without data transferring or not setup at all.

FIGs. 9-10 show message flow diagrams according to embodiments. With reference to FIG. 9, in the LFA procedure, HR-BS 5 detects the LF opportunity for the source HR-MS 9 after HR-MS 7 initiates the connection setup to the destination HR-MS 11. HR-RS 7 is instructed to perform LF for HR-MS 9 and HR-MS 11. In FIG. 9, the messaging 159 between HR-BS 5 and ASN 155 is illustrated but not shown in detail.

[0081] Alternatively, if the detection is performed to find out the LF opportunity after connection establishment, HR infrastructure station can initiate the similar handshaking process to set up the LF. If HR-BS 5 initiates the handshaking with HR-RS 7 for LF, it will send AAI-LFA-REQ 161 to HR-RS 7. After that HR-RS 7 should respond with AAI- LFA-RSP 163 and perform LF as described. If HR-RS 7 initiates the handshaking with HR-BS 5 for local forwarding, it will send an AAI-LFA-REQ to HR-BS 5. HR-BS 5 shall response with an AAI-LFA-RSP for the received AAI-LFA-REQ and performs local forwarding as described. Either HR-BS 5 or HR-RS 7 may communicate with ASN 155 entities to remove data path for the corresponding uplink flow from the source HR- MS and the corresponding downlink flow to the destination HR-MS 11. Besides these messages, after receiving AAI-LFA-REQ 161, HR-RS 7 may send a DSA or DSC message to HR-BS 5 to reflect the changed QoS requirement on the relay link.

[0082] With reference to FIG.10, in the LFA procedure, HR-BS 5 detects the LF for the source HR-MS 9 during data forwarding, and HR-RS 7 is instructed to perform LF for HR-MS 9 and HR-MS 11. FIG. 10 thus shows a further embodiment as described in the previous paragraph.

[0083] To terminate the LF, HR infrastructure station may use AAI-LFD- REQ/RSP/ACK to end LF. When HR infrastructure station receives control message AAI-DSD-REQ from HR-MS (the source and/or the destination) to terminate the connection or it decides to stop LF due to other reasons, it may proceed with the handshaking procedure similar to the setup for LF. When HR-RS initiates the termination procedure after receiving AAI-DSD-REQ, it responds with AAI-DSD-RSP and the HR- MS will acknowledge with AAI-DSD-ACK. HR-RS also sends AAI-LFD-REQ to its HR-BS, which responds with AAI-LFD-RSP. HR-RS will acknowledge with AAI-LFD- ACK. HR-BS shall also send AAI-DSD-REQ to the other HR-MS to terminate the connection, following the normal procedure of connection termination.

[0084] When only LF is determined to stop, HR infrastructure station shall proceed with the handshaking using AAI-LFD-REQ/RSP/ACK without terminating the current connection. HR infrastructure station may setup the data path through ASN entities for the two communicating HS-MSs to maintain connectivity.

[0085] AAI-LFD-REQ Message Field description

[0086] AAI-LFD-RSP Message Field description

[0087] AAI-LFD-ACK Message Field description

FID 4 Downlink FID of Shall always

destination HR-MS Present

or multicast specific

FID that is

associated with

multicast group ID

Confirmation Code 1 Zero indicates the Shall always

request was Present

successful. Nonzero

indicates failure

[0088] When LF is determined and the FIDs for uplink flow from the source to its serving infrastructure station and downlink flow from the serving infrastructure station to the destination HR-MS are assigned after connection setup, HR-infrastructure station shall forward the received data traffic from the source HR-MS to the destination HR-MS locally based on STIDs of the source HR-MS and the destination HR-MS, uplink FID of the source HR-MS and downlink FID of the destination HR-MS. When the field of Backup Option is set as Ob 1 during LFA procedure (AAI-LFA- REQ/RSP/ACK), the data flow for the uplink shall be forwarded by HR infrastructure station accordingly.

When the field of Backup Option is set as ObO during LFA procedure (AAI-LFA- REQ/RSP/ACK),

° if HR-RS performs the LF, the data traffic shall be forward by HR-RS without going through HR-BS;

° if HR-BS performs the LF, the data traffic shall be forward by HR-BS without going through backhaul.

[0089] When the LF opportunity is determined during data traffic forwarding after connection establishment and LF can be done through HR-RS, its serving HR-BS shall continue to deliver the data to maintain the connectivity of downlink flow to the destination HR-MS and forwarding HR-RS will forward the data locally to the destination HR-MS once the setup of LF is complete. The forwarding from HR-RS to HR-BS for the uplink flow and/or from HR-BS to HR-RS for the downlink flow regarding to two communicating HR-MSs may continue till the transmissions of the data for uplink and/or downlink finish.

[0090] The data traffic forwarded locally by HR-RS shall follow MAC PDU formats in 16.2.2 and construction and transmission of MPDUs shall follow 16.2.3. The data traffic forwarded locally by HR-BS shall follow MAC PDU formats in 6.2.2 and construction and transmission of MPDUs shall proceed.

[0091] In handover, there are two cases for LF: case 1) when either the source or the destination is going out of the control of serving infrastructure station that performs LF for it; case 2) when both the source and the destination HR-MSs are going to be under the control of the same infrastructure station that shall perform LF for them.

[0092] In case 1, serving infrastructure station has to relinquish the LF since source and destination are not under the same infrastructure station anymore. This results in the connection re-establishment after handover, which is same as the normal procedure without LF. After the connection re-establishment, data flow forwarding shall follow the normal procedure without LF. HR-infrastructure station may update ASN entities on the removal of LF. The details of the messages ((e.g. PATH REG REQ/RSP/ACK and RR REQ/RSP/ACK)) are out of scope.

[0093] In case 2, after handover, the target infrastructure station or its associated ASN shall detect the LF opportunity for the HR-MS being handed over. During the connection re-establishment or data flow forwarding, once the opportunity of local forward is determined, the target infrastructure station performs LF for the data traffic based on STIDs of source and destination, uplink FID of source and downlink FID of destination. [0094] For both cases, the control messages of AAI-LFA-REQ/RSP/ACK and AAI- LFD-REQ/RSP/ACK shall be used for the handshaking between HR-BS and HR-BS as described, if required.

[0095] The above description is applied to multicast service such as PTT (Push-To- Talk). For STID field in the control messages, it refers to multicast STID. The LF can be done by HR infrastructure station (HR-BS/HR-RS). The procedure for setup the multicast service in MAC layer includes the following:

[0096] The uplink setup of the source HR-MS.

[0097] The downlink setup for multicast specific FID that is associated with multicast group ID for the multicast group members HR-MSs (as the downlink destinations).

[0098] When HR infrastructure station detects and determines the LF opportunity, the messaging between HR-BS and HR-RS may occur.

1. If HR-BS detects the LF opportunity that its HR-RS can perform LF, it sends AAI- LFA-REQ to HR-RS.

2. If HR-RS detects the LF opportunity that it can perform LF, it sends AAI-LFA-REQ to HR-BS.

3. The handshaking procedure is complete with AAI-LFA-RSP/ACK between HR-BS and HR-RS.

[0099] When HR infrastructure station perform local forwarding for multicast

1. If only HR-BS performs LF, it locally forwards the data traffic from uplink flow to multicast group members through downlink multicast specific FID, without through backhaul. In this case all the multicast group members are associated with the same HR- BS.

2. If only HR-RS performs LF, it locally forwards the data traffic from uplink flow to multicast group members through downlink multicast specific FID, without through HR- BS. In this case all the multicast group members are associated with the same HR-RS. 3. If both HR-BS and HR-RS perform LF and HR-RS locally forwards the data traffic from downlink flow to some of multicast group members that are associated with it through downlink multicast specific FID, HR-RS also forwards the data traffic through its uplink to its associated HR-BS.

[00100] If all other multicast group members that are associated with the same HR-BS, the HR-BS performs LF. The HR-BS locally forwards the data traffic from uplink flow to all other multicast group members that are not associated with the HR-RS through downlink multicast specific FID, without through backhaul.

[0100] If all other multicast group members that are not associated with the same HR- BS. HR-BS performs LF, it locally forwards the data traffic from uplink flow to all other multicast group members through downlink multicast specific FID either directly or indirectly through other HR-RS with which some multicast group members are associated, without through backhaul.

[0101] The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative, not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

What is claimed is:

1. An infrastructure station for performing direct local forwarding in a cellular mobile communication system which includes a core network, the infrastructure station comprising:

a transceiver;

a detector configured to detect a local forwarding opportunity between at least two mobile stations under the control of the infrastructure station based on received transmissions;

a binder configured to bind an uplink flow and a downlink flow together into a data flow route between the at least two mobile stations, wherein the uplink flow and the downlink flow are identified by uniquely identifiable station flow identifiers, and wherein the station flow identifiers are unique service flow identifiers, a composition of at least a uniquely identifiable station identifier and a uniquely identifiable flow identifier or connection identifiers; and

a forwarder configured to forward received data from the at least two mobile stations by employing a station flow identifier provided in received data transmissions to determine the data route flow.

2. The infrastructure station as in claim 1, wherein the infrastructure station is a base station and the detector for detecting a local forwarding opportunity between at least two mobile stations under the control of the infrastructure station based on received transmissions is configured to perform the following:

receive a DSC/DSA-REQ transmission;

decode a source and a destination encoded in the transmission;

detect that the source and the destination are both under the control of the base station; and

respond to the DSC/DSA-REQ and initiate a new DSC/DSA-REQ for local forwarding.

3. The infrastructure station as in claim 1, wherein the infrastructure station is a relay station and the detector for detecting a local forwarding opportunity between at least two mobile stations under the control of the infrastructure station based on received transmissions is configured to perform the following:

receive a DSC/DSA-REQ transmission;

decode a source and a destination encoded in the transmission;

detect that the source and the destination are both under the control of the relay station;

transmit a control message to the core network to setup a data path, a DSC/DSA-REQ for local forwarding; and

receive a DSC/DSA-RSP and initiate a new DSC/DSA-REQ for local forwarding.

4. The infrastructure station as in any of claims 1-3, the infrastructure station further comprising a multicaster configured to maintain a table that stores source and destination address pairs for a plurality of downlink connections in a detected multicast packet, wherein the binder is configured to bind a downlink multicast flow with an uplink unicast flow, and wherein the station flow identifiers are unique service flow identifiers, a composition of at least a uniquely identifiable multicast group identifier and a uniquely identifiable flow identifier, or connection identifiers.

5. The infrastructure station as in any of claims 1-4, wherein the infrastructure station is configured to forward data from more than one hop away.

6. The infrastructure station as in any of claims 1-5, further comprising a handover module configured to a station handover where one of the at least two mobile stations moves out of local forwarding control of the infrastructure station and removes the data flow thereto.

7. The infrastructure station as in any of claims 1-6, the handover module further configured to detect a station handover where the at least two mobile stations remain under local forwarding control of the infrastructure station and re-establish local forwarding after the station handover.

8. A method for performing direct local forwarding in a cellular mobile communication system which includes a core network, the method comprising:

detecting a local forwarding opportunity between at least two mobile stations under the control of an infrastructure station based on received transmissions;

binding an uplink flow and a downlink flow together into a data flow route between the at least two mobile stations, wherein the uplink flow and the downlink flow are identified by uniquely identifiable station flow identifiers, and wherein the station flow identifiers are unique service flow identifier, a composition of at least a uniquely identifiable station identifier and a uniquely identifiable flow identifier, or connection identifiers; and

forwarding received data from the at least two mobile stations by employing a station flow identifier provided in received data transmissions to determine the data route flow.

9. The method as in claim 8, wherein detecting a local forwarding opportunity between at least two mobile stations under the control of an infrastructure station based on received transmissions comprises a core network detecting the local forwarding opportunity during data forwarding.

10. The method as in claim 8, wherein detecting a local forwarding opportunity between at least two mobile stations under the control of an infrastructure station based on received transmissions comprises an infrastructure station detecting the local forwarding opportunity during flow setup.

11. The method as in claim 8, wherein detecting a local forwarding opportunity between at least two mobile stations under the control of an infrastructure station based on received transmissions comprises:

receiving a DSC/DSA-REQ transmission at a base station; decoding a source and a destination encoded in the transmission;

detecting that the source and the destination are both under the control of the base station; and

responding to the DSC/DSA-REQ and initiate a new DSC/DSA-REQ for local forwarding.

12. The method as in claim 8, wherein detecting a local forwarding opportunity between at least two mobile stations under the control of an infrastructure station based on received transmissions comprises:

receiving a DSC/DSA-REQ transmission at a relay station;

decoding a source and a destination encoded in the transmission;

detecting that the source and the destination are both under the control of the relay station;

transmitting a control message to the core network to setup a data path, a DSC/DSA- REQ for local forwarding; and

receiving a DSC/DSA-RSP and initiate a new DSC/DSA-REQ for local forwarding.

13. The method as in claim 8, wherein detecting a local forwarding opportunity between at least two mobile stations under the control of an infrastructure station based on received transmissions comprises:

receiving a DSC/DSA-REQ transmission at the common infrastructure station;

transmitting control messages to a core network to setup data paths for the at least two mobile stations;

detecting with the core network that a source and a destination are both under the control of the common infrastructure station; and

instructing the common infrastructure station to perform local forwarding.

14. The method as in any of claims 8-13, the method further comprising:

maintaining a table that stores source and destination address pairs for a plurality of downlink connections in a detected multicast packet, wherein the downlink flow is a multicast downlink flow, and

wherein the station flow identifiers are unique service flow identifier, a composition of at least a uniquely identifiable station identifier and a uniquely identifiable flow identifier, or connection identifiers.

15. The method as in any of claims 8-14, wherein the forwarder is configured to forward data from more than one hop away.

16. The method as in any of claims 8-15, further comprising:

detecting a station handover where one of the at least two mobile stations moves out of local forwarding control of the infrastructure station; and

removing the data flow route.

17. The method as in any of claims 8-16, further comprising:

detecting a station handover where the at least two mobile stations remain under local forwarding control of the infrastructure station; and

re-establishing local forwarding after the station handover.

18. The method as in claim 17, further comprising negotiating local forwarding capabilities with a network entry control message, the network entry control message indicating one of:

that the relay station does not support local forwarding;

that the relay station is capable of detecting local forwarding opportunities and performing local forwarding; or

that the relay station is not capable of detecting local forwarding opportunities but is capable of performing local forwarding.

19. The method as in claim 18, further comprising responding to the network entry control message, the response indicating one of:

that the relay station is not permitted to support local forwarding;

that the base station will detect local forwarding opportunities and the relay station will perform the local forwarding;

that the relay station will detect local forwarding opportunities and perform the local forwarding; or

that the core network will detect local forwarding opportunities and the relay station will perform the local forwarding.