WO2013009892A1 - Systems and methods for establishing and maintaining multiple cellular connections and/or interfaces - Google Patents

Abstract

Systems and methods for providing multiple connections or interfaces at the same time may be disclosed herein. For example, in an embodiment, a first RRC connection may be established between a wireless transmit and receive unit (WTRU) or user equipment (UE) and network node such as an eNB and a second RRC connection may be established between the WTRU or UE and the network node such as the eNB or another network node such as another eNB. The first RRC connection and the second RRC connections may then be maintained in parallel (e.g. at the same time).

Description

[0001] Today, a device such as user equipment that may be used in a communication system may be connected to a network node such as an eNB. When the network node may be degraded or additional bandwidth may be available on another network node such as another eNB, a. connection such as an RRC connection to the other network node may be established and a connection such as an RRC connection to the original network node may be torn down.

Currently, one connection with one network node may be established, maintained, and/or supported at one time or at the same time.

SUMMARY

[0002] Systems and methods for providing multiple connections (e.g. cellular connections) at the same time may be disclosed herein. For example, in an embodiment, a first RRC connection may be established between a wireless transmit and receive unit (WTRU) or user equipment (UE) and a network node such as an eNB and a second RRC connection may be established between the WTRU or UE and the network node such as the eNB or another network node such as another eNB. The first RRC connection and the second RRC connection may then be maintained in parallel (e.g. at the same time). Additional RRC connections (e.g. a third RRC connection, a fourth RRC connection, and the like) may also be established and maintained in parallel with the first and second RRC connections,

[0003] According to an embodiment, a first, bearer and a second bearer that may be independent of the first bearer (e.g. the first and second bearer may be independent of each other) may also be provided and/or used herein. For example, the WTRU or UE may be attached to a core network via the first network node and the first bearer may be established between the WTRU or UE and the core network via the first network node and a second bearer may be established between the WTRU or UE and the core network via the second network node. In an embodiment, no connection may exist between the second network node and the core network.

I The core network may establish the second bearer via the second network node using signaling via the first network node and the second bearer is modified using signaling via the first network node. Additionally, the first bearer may be associated with the first RRC connection and the second bearer may be associated with the second RRC connection.

[0004] In example embodiments, at least a portion of an IP flo w may be configured to be moved from the first RRC connection to the second RRC connection and/or the first bearer may be configured to be moved from the first RRC¹ connection to the second RRC connection.

[0005] The Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, not is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to any limitations that solve any or all disadvantages noted in any part of this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] A more detailed understanding of the embodiments disclosed herein may be had from the following description, given by way of example in conjunction with the accompanying drawings.

[0007] FIG. 1 is a block diagram illustrating example system in which management of flow communication flow at an IP layer may be performed.

[0008] FIG. 2 is a block diagram illustrating another example system in which management of flow communication flow at an I P layer may be performed.

[0009] FIG, 3 is a block diagram illustrating another example system in which management of flow communication flow at an IP layer may be performed.

[0010] FIG. 4 is a block diagram illustrating a portion of the system of any of FIGs. 1-3 and certain connections between el ements of such system.

[001 1] FIG. 5 is a diagram illustrating an example PDN connection map of eNB-SGW tunnels of default and dedicated bearers of a PDN connection.

[0012] FIG. 6 is a diagram illustrating an example PDN connection map of eNB-SGW tunnels of two default bearers of respective PDN connections to the same PDN. [0013] FIG. 7 is a diagram illustrating an example PDN connection map of eNB-SGW tunnels of defaul t and dedicated bearers of a PDN connection to the same PDN from a single base station.

[0014] FIG. 8 is a diagram illustrating an example PDN connection map of eNB-SGW tunnels of two default bearers of respective PDN connections to different PDNs.

[0015] FIGs. 9-20 are message sequence charts illustrating call flows for performing one or more of procedures or functions described herein.

[0016] FIG, 21 is a block diagram illustrating another example system in which

management of flow communication flow at an IP layer may be performed.

[0017] FIG. 22 is a block diagram illustrating another example system in which management of flow communication flow at an IP layer may be performed .

[0018] FIGs 23-24 are block diagrams illustrating another example system in which management of flow communication flow at an IP layer may be performed.

[0019] FIG. 25 is a block diagram illustrating at least a portion of an example system in which IP flow management may be performed.

[0020] FIG. 26 is a diagram illustrating an example PDN connection map of eNB-SGW broken tunnels at a BWMC of two default bearers of different PDN connections to same PDN.

[0021] FIG. 27 is a diagram illustrating an example PDN connection map of eNB-SGW broken tunnels at BWMC of default and default bearers of a PDN connection to a PDN from the same eNB.

[0022] FIG. 28 is a diagram illustrating an example PDN connection map of eNB-SGW broken tunnels at BWMC of two default bearers of different PDN connections to different PDNs. The PDN connection 1 and PDN connection 2 map to PDN! and PDN2 respectively.

[0023] FIGs. 29-43 are message sequence charts illustrating call flows for performing one or more of procedures or functions described herein

[0024] FIG. 44 is a block diagram illustrating example system in which multiple RRC connections may be established and marinated.

[0025] FIG. 45 is a diagram illustrating an example PDN connection map of eN B-SGW tunnels of two default bearers of respective PDN connections to different PDNs via multiple PGVVs. [0026] FIG. 46 is a diagram illustrating connections such as logical connections and RRC connections across multiple eNBs.

[0027] FIG. 47 is an example flow chart of an example method and a subset of procedures associated therewith for establishing and maintaining multiple connections such as multiple RRC connections.

[0028] FIGs. 48-68 are example message sequence charts illustrating call flows for performing one or more of procedures or functions described herein.

[0029] FIG. 69 illustrates an example embodiment of multiple IP flows.

[0030] FIG. 70 illustrates an example embodiment of bearer mobility.

[0031] FIG. 71 illustrates an example embodiment of IP flow mobility.

[0032] FIGs. 72-76 are example message sequence charts illustrating call flows for performing one or more of procedures or functions described herein.

[0033] FIGs. 77-78 depict block diagrams illustrating example system with a BWMC and in which multiple RRC connections may be established and marinated.

[0034] FIG. 79 is a diagram illustrating an example PDN connection map of eNB-SGW tunnels that may be broken at a BWMC of default and dedicated bearers of a PDN connection.

[0035] FIG. 80 is a diagram illustrating an example PDN connection map of eNB-SG W tunnels that may be broken at a BWMC of two default bearers of respective PDN connections to the same PDN.

[0036] FIG. 81 is a diagram illustrating an example PDN connection map of eNB-SG W tunnels that may be broken at a BWMC of default and dedicated default bearers of respective PDN connections to the same PDN.

[0037] FIG. 82 is a diagram illustrating an example PDN connection map of eNB-SGW tunnels that may be broken at a BWMC of two default bearers of respective PDN connections to different PDNs.

[0038] FIG. 83 is a diagram illustrating connections such as logical connections and RRC connections across multiple eNBs and a BWMC.

[0039] FIG. 84A depicts a diagram of an example communications system in which one or more disclosed embodiments may be implemented.

[0040] FIG. 84B depicts a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 84A. [0041] FIG. 84C depicts a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 84A.

[0042] FIG. 84D depicts a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 84A.

[0043] FIG. 84E depicts a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 84A.

DETAILED DESCRIPTION

[0044] A detailed description of illustrative embodiments will now be described with reference to the various Figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

[0045] Systems and/or methods for providing multiple radio resource control (RRC) connections within a communication network may be disclosed herein. As described above, typically one RRC connection may be provided and/or used in one communication network. Systems and methods disclosed herein may maintain multiple RRC connections within a communication network.

[0046] For example, as more and more small cells (e.g., microcelis, picocells, femtocells, and the like) may be deployed, a user's mobile equipment (UE) may establish multiple simultaneous connections with multiple radio stations (e.g. Node Bs (NBs), evolved NBs (eNBs), Home NBs (HNBs), Home eNBs (HeNBs), base stations (BSs), and the like.). In such embodiments, data rates may be increased by aggregating bandwidth across the multiple connections; load balancing may be achieved by moving data from a heavily loaded connection to a lightly loaded one; fault tolerance and robustness may be provided by using the good connection when the other fails or otherwise is degraded; and the like. Current solutions (e.g. a soft handover, Co P, and/or CA) may be provided at the radio interface protocols level.

Unfortunately, this may call for tight coordination between the multiple radio connections as described herein. The IP-protocol -level coordinated multi-point transmission of packet data communications described herein may have an advantage of looser coordination between the multiple connections and of re-using existing IP-Flow Mobility solutions such as DSMIP, PMIP, and the like.

[0047] The methods, systems and apparatuses for IP-Level Coordinated Multi-Point

Transmission of Packet-Data Communications, as described herein, may be implemented as cellular network extensions enabling IP flow management for a UE across simultaneous connections with multiple (H)eNBs and multiple RRC connections. As described in more detail below, the UE may initiate connectivity with multiple (H)eNBs simultaneously such that the UE may make use of the available interfaces for uplink and downlink traffic. Once registered with a network such as a LTE network, the LIE may send out or exchange the control and/or user plane messages or data on an available interface. The UE may choose an available interface for uplink traffic, and the UE may accept downlink traffic on an available interface. Additionally, such an embodiment may be viewed as an application of 3GPP/Non 3 GPP interworking solutions to a 3GPP solution where the interworking may apply across multiple eNBs or base stations belonging to 2G or 3G (e.g. UMTS, HSPA) or 4G (e.g. LTE, LTE -A) access networks. This may be an advantage over a current soft handover, coordinated multi-point (CoMP), and/or carrier aggregation (C A) solutions or methods, which may be restricted to a single radio access network due to tight coordination requirements.

[0048] FIG 1 is a block diagram illustrating example system 10 in which management of communication flows at an IP layer (e.g. IP flow management) may be performed. The system 10 may include various elements which may and may not be in FIG. 1 . Detai ls of an example architecture of a system and its associated elements, which may be representative of the system 10 and its elements, may be described with reference to FIGs 84A-84E. According to an embodiment, the system 10 may be a mobile wireless broadband standard Long Term Evolution (LTE) and its associated Evolved Packet System (EPS) architecture. Additionally, the system (or methods) such as the system 10 described herein for IP -Level Coordinated Multi-Point Transmission of Packet-Data Communications may be formatted in accordance with other mobile wireless protocols such as GPRS, UMTS, HSPA, LTE-A, and the like.

[0049] According to example embodiments, a UE and an eNBI may be configured to be communicatively coupled and may be configured to establish connections therebetween using a first LTE-Uu interface such as LTE-Uul . The UE and an eNB2 may be configured to be communicatively coupled and may be configured to establish connections therebetween using a second LTE-Uu interface such as LTE-Uu2. The LTE-Uul and LTE-Uu2 may define respective protocol stacks. The LTE-Uul and LTE-Uu2 interfaces, protocol stacks and elements thereof may be defined in accordance with LTE (e.g. as currently promulgated) along with changes, modifications and/or the like thereto d sclosed herein.

[0050] FIG. 2 is a block diagram illustrating alternative example system 20 in which IP flow management may be performed. The system 20 of FIG. 2 may be similar to the system 10 of FIG. 1 (e.g. except as described herein). As shown in FIG. 2, the eNBl and eNB2 may be replaced by two home eNBs (HeNBs) such as HeNBl and eN B2. Also, the system 20 may include a HeNB gateway (HeNB-GW) communicatively coupled between the HeNBl and BeNB2 and a serving gateway (SGW).

[0051] FIG. 4 is a block diagram illustrating a portion of the system 10 and certain connections between elements of the system 10. As shown in FIG. 4, a first RRC connection may be established between the UE and eNBl . Additionally, a second RRC connection may be established between the UE and eNB2.

[0052] Additionally, logical SI connections for the UE (e.g. UE-associated logical SI - connections) may be established between the eNBl and MME (e.g. eNBl -MME logical S l- connection 1) and between the eNB2 and MME (e.g. eNB2-MME logical SI -connection 1). The eNBl -MME logical SI -connection 1 and the eNB2-MME logical SI -connection 1 may be identified by respective identities MME UE SIAP ID, eNB UE SI AP ID. For example, the eNBl -MME logical SI -connection 1 may be identified by identities eNBl UE SI AP ID 1, MME UE SLAP ID1. The eNB2-MME logical SI -connection 1 may be identified by identities eNB2 UE SI AP IDl , MME UE SI AP ID2.

[0053] According to example embodiments, for a received LIE associated Sl-AP message, the MME may identify the associated UE via uplink messages based on the MME UE SI AP ID IE, and the appropriate eNB may identify the associated UE via downlmk messages based on the eNB UE SIAP ID IE. The eNBs and MME may generate a unique eNB UE SI AP ID and MME LIE SIAP ID locally. Also, when multiple eNB(s) connect to the MME, the MME may maintain a corresponding number of UE-associated logical SI -connections for each LIE on eNB-MME interface. [0054] FIG. 5 is a diagram illustrating an example PDN connection map (e.g. that may be established by the MME) of eNB-SGW tunnels of default and dedicated bearers of a PDN connection (e.g. PDN connection 1). In an example embodiment, for example, because the default and dedicated bearers belong to the same PDN connection 1, such bearers may share the same IP address, but such bearers may have different bearer ids. As shown in FIG. 5, the PDN connection map may include an eNBI-SGW tunnel of the default bearer of the PDN connection I such as PDN connection 1 (default bearer (IP address 1, bearer idl)). The PDN connection map may also include an eNB2-SGW tunnel of the dedicated bearer of the PDN connection 1, such as PDN connection 1 (dedicated bearer (IP address 1 , bearer id2)).

[0055] In an embodiment, the eNBl-SGW tunnel may define two tunnel endpoints (TEs), and in general, each of the TEs may be identified with a TE identifier (TEID), an IP address and a UDP port number. The TEID may unambiguously identify the TE in scope of a path. For example, the TEIDs for eNBI-SGW tunnel may be represented by eNBl TEID1 and

SGW_TEID1. The eNB2-SGW tunnel may also defines two TEs, for example, represented by eNB2 TEID1 and SGW TEID2.

[0056] FIG. 6 is a diagram illustrating an example PDN connection map (e.g. that may be established by the MME) of eN B-SGW tunnels of two default bearers of respective PDN connections such as PDN connection 1 and PDN connection 2 associated with, for example, the same PDN. In an embodiment, the bearers associated therewith or used thereby may have different IP addresses as well as different bearer ids. As shown in FIG. 6, the PDN connection map may include an eNBl-SGW tunnel of the default bearer of the PDN connection 1 such as PDN connection I (default bearer (IP address 1, bearer idl)). The PDN connection map may also include an eNB2~SGW tunnel of the default bearer of the PDN connection 2 such as PDN connection 2 (default bearer (IP address 2, bearer id2)).

[0057] Similar to embodiments described above, the eNBl-SGW tunnel may define two TEs. The TEIDs for eNBl-SGW tunnel may be represented by eNBl__TEIDI and SGWJTEIDl . The eNB2-SGW tunnel may further define two TEs and the associated TEIDs may be

represented by eNB2_TEIDl and SGW_TEID2.

[0058] FIG. 8 is a diagram illustrating an example PDN connection map (e.g. that may be established by the E) of eNB-SGW tunnels of two default bearers of respective PDN connections such as PDN connection 1 and PDN connection 2 associated with, for example, different PDNs. According to an example embodiment (e.g. because the default bearers may belong to different PDN connections), such bearers may have different IP addresses. The bearers may also have different bearer ids. As shown in FIG. 8, the PDN connection map may include an eNBl-SGW turmel of the default bearer of the PDN connection 1 such as PDN connection 1 (default bearer (IP address 1 , bearer idl). The PDN connection map may also include an eNB - SGW tunnel of the default bearer of the PDN connection 2 such as PDN connection 2 (default bearer (IP address 2, bearer id2).

[0059] Similar to embodiments described above, the eNBI-SGW tunnel may define two TEs, and the TEIDs for eNBl-SGW tunnel may be represented by eNBl TEID1 and

SGW TEIDl . The eNB2-SGW tunnel may also define two TEs, and the associated TEIDs may be represented by eNB2 TEID1 and SGW TEID2. According to an example embodiment, the (H)eNBs may belong to a same tracking area, and may be served by the same MME and SGW. Further, the UE may be capable of accessing multiple (H)eNBs at the same time.

[0060] Additionally, in embodiments, separate tunnels may be created from (H)eNBs to the SGW with QoS treatment for the default and/or dedicated bearers. For example, based on Sl-U information available at the SGW, the SGW may send the traffic on the respective tunnels (TEIDs) to the respective (H)eNBs. As such TEIDs may be mapped to bearers on (H)eNBs, the data may be sent to the UE on such bearers by (H)eNBs. The UE may send then send user plane data to (H)eNBs. The (H)eNBs, based on the Sl-U information available, may send the traffic on the respective turmel (TEID) to the SGW.

[0061] BWM-MME functions may be provided and/or used as described herein. For example, the MME may be configured to perform bandwidth management (BWM-MME) functions. The BWM-MM E functions may include one or more of the following: an

Attach/Registration procedure, a Detach/Deregistration procedure; a PDN connectivity request on multiple interfaces, uplink traffic on multiple interfaces, downlink traffic on multiple interfaces, Capability to have default and dedicated bearers of a PDN across (H)eNBs, load balancing (e.g., distribution of dedicated bearers across (H)eNBs), failover (e.g., re-establishing bearers on available interfaces during unavailability of any interface), and the like.

[0062] An attach and/or registration procedure on multiple interfaces may also be provided and/or performed. For example, a UE and LTE network may perform or use an attach procedure to carry out registration of the UE with or via the LTE network. In one embodiment, the UE may send to the eNBl, via the LTE-Uu 1, an attach request. Alternatively and/or additionally, the UE may choose an LTE-Uu interface associated with the other eNBs (e.g. eNB2) that may be available. The eNB l and MME may then create a Sl-MME logical SI -connection 1 , and may send (e.g. to the MME) a first NAS : ATTACK-REQUEST message and a first NAS:PDN CONNECTIVITY REQUEST message. The Sl-U tunnels may then be established between a (H)eNB and SOW.

[0063] in one embodiment, after establishing RRC connections with available (H)e^'NBs, the UE may send a NAS: ATTACH REQUEST message on an LTE-Uu interface with a (H)eNB (e.g. LTE-Uu 1) to register with the network. After the registration and/or attach procedure may be performed or completed, the UE may then send a NAS:PDN CONNECTIVITY REQU EST OR NAS:BEARER RESOURCE ALLOCATION REQUEST on secondary LTE-Uu interfaces (e.g., LTE-Uu2) to use secondary (H)eNBs.

[0064] Additionally, a detach and/or deregistration procedure on multiple interfaces may be provided and/or performed. For example, a UE and/or a network may initiate a detach. For a LIE initiated detach, the UE may have an option of sending a detach request on any (H)eNB that may be connected to the M ME. The MME, in turn, may clean up Sl-MM E connections (e.g. physical and/or logical) between the (H)eNBs and the MME. For a network (e.g.,

HSS/MM E/PGW/SGW) initiated detach, the MME may send a detach request to the UE on (H)eNBs, and may clean up Sl-MME connections (e.g. physical and/or logical) between the (H)eNBs and the MME.

[0065] In an embodiment, when default and/or dedicated bearers of a PDN may be distributed across multiple (H)eNBs, and a default bearer of a PDN may be released by, for example, the UE, MME, SGW, and/or PGW, the M ME may send to the respective (H)eNBs appropriate S1AP:E-RAB RELEASE COMMANDS having the corresponding bearer ids in the NAS PDUs. According to an example embodiment, the UE should not send multiple detach requests to the MME, but the MME may be handle such multiple requests if they may occur.

[0066] A PDN connectivity request on multiple interfaces may also be provided and/or used. For example, the PDN connection creation procedure may be used by a LIE to create a standalone PDN connection. The LIE may obtain an IP address for a newly created PDN connection. In an embodiment, "stand-alone" may refer to the case of PDN connection creation rather than a combination of the attach and PDN connection procedures. [0067] When a standalone PDN connectivity request may be received from a UE on a (H)eNB, the MME may follow a standard procedure to setup a PDN connection. The PDN connectivity request may be on a (H)eNB that may be different from the (H)eNB where the attach procedure may have been performed or done.

[0068] The default and/or dedicated bearers of a PDN may be distributed across multiple (H)eNBs, but each of them may have the same UE IP address. In such an embodiment, such (H)eNBs may be served by the same SGW. For a PDN, the bearers may have the same UE IP address. According to an embodiment, multiple links may have multiple IP addresses. The bearers (e.g. default and/or dedicated bearers) of the PDN may map to different (H)eNBs, for example, to have single UE IP addresses. In some embodiments, the UE may have multiple (e.g. 8) different PDN connections and, as such, multiple (e.g. 8) different IP addresses.

[0069] Uplink traffic and/or downlink traffic on multiple interfaces may be provided and/or used as described herein. For example, a UE may send across user plane traffic (e.g. uplink) on multiple bearers that may have been created. In an embodiment, the (H)eNB may use a TEID of a SGW for the bearer to send the user plane traffic. Additionally, the SGW⁷ may use the TEID(s) of (H)eNB(s) for the bearer to send the user plane traffic (e.g. downlink).

[0070] A capability to have default and/or dedicated bearers of a PDN across (H)eNBs may be provided as described herein. For example, a MME may distribute the default and/or dedicated bearers of a PDN across multiple (H)eNBs (e.g., (H)eNBs that may be served by the same SGW). During a detach, when a default bearer or default bearers of a PDN may be released, the MME may release the dedicated bearers of the PDN (e.g. even if the dedicated bearers may be spread across multiple (H)eNBs).

[0071 ] Additionally, load balancing including distribution of dedicated bearers across (H)eNBs. For example, a MME may distribute the dedicated bearers of a PDN across multiple (H)eNBs based on, for example, loading conditions of the network. The MME may select one or more lightly loaded (H)eNBs to establish dedicated bearers. In such examples, the MME may use each of the interfaces available to the UE.

[0072] A failover including re-establishing bearers on available interfaces during an unavailability of an interface may be provided and/or used. For example, a MME may reestablish the bearers on available (H)eNBs, when the MME may detect that one or more of the (H)eNBs may be down. [0073] Message sequence charts (MSCs) or flows that may illustrate methods or procedures may be provided and/or used as described herein. FIGs. 9-20 depict MSCs illustrating call flows for performing one or more of BWM-MME functions. The MSCs may be described below with reference to FIGs. 1 -8. Authentication related message exchanges between UE/MME/HSS may also be provided and/or used.

[0074] In one embodiment, a S I AP message (e.g. SIAP: INITIAL UE MESSAGE) from an eNBl to a MME may be sent and/or received. For example, in a call flow, when the MME may receive a SIAP message from eNBl, the SIAP message may include the eNB UE SIAP ID parameter and/or IE set to eNBl UE SIAP ID1. The SI AP message may not include the MME UE SIAP ID parameter and/or IE, because no logical S 1 -connection (e.g. eNB l -MME logical SI -connection 1) may exist for the combination of the eNBl, MME, and/or UE. The eNBl may generate a unique eNBl UE SIAP ID 1, and may include it in the SIAP message. The MME may generate a unique MME UE SIAP ID1 for a newly created logical SI -connection (e.g. eNBl- MME logical SI -connection 1 ) for the combination of the eNBl , MME, and/or UE.

[0075] A SIAP message (e.g. a reply to a S1AP:INITIAL UE MESSAGE) from a MME to eNBl may be sent and/or received. For example, in a call flow, when the eNBl may receive a S IAP message from the MME, the S IAP message may include the eNB UE SIAP ID parameter and/or IE set to eNBl UE SIAP ID! and the MM E UE SI AP ID parameter and/or IE set to MME UE S LAP ID 1. The above procedure or method may be applicable for eNB2 as well.

[0076] A SIAP message (e.g. except SI AP: INITIAL UE MESSAGE) from an eNBl to a MME may be sent and/or received. For example, in a call flow, when the MME may receive a SIAP message from the eNBl, the SIAP message may include the eNB UE SLAP ID parameter and/or IE set to eNB 1 UE S 1 AP ID 1 , and the M ME UE S 1 AP ID parameter and/or IE set to MME UE SLAP ID 1.

[0077] Additionally, a S 1 AP message (e.g. except S 1 AP:INITIAL UE MESSAGE) from a MME to an eNBl may be sent and/or received. For example, in a call flow, when the eNBl may receive a SI AP message from the MME, the SIAP message may include the eNB UE SIAP ID parameter and/or IE set to eNBl UE SIAP ID1, and the MME UE SIAP ID parameter and/^'orlE set to MME UE SLAP ID1. The above procedure or method may be applicable for eNB2 as well. [0078] Example procedures and/or methods for distributing default and/or dedicated bearers of a PDN across (H)eNBs may be provided and/or used. In one embodiment, the default and/or dedicated bearers may have the same IP address, but different bearer ids. The default and or dedicated bearers of a PDN may be distributed across multiple (H)eNBs by performing an attach procedure followed by a UE initiated dedicated bearer activation. An example attach procedure (e.g. an LTE attach procedure or method) that may be used herein may be illustrated in FIG. 9. According to an example embodiment, the attach procedure (e.g. shown in FIG. 9) may be performed to register the UE with the LTE network.

[0079] FIG. 10 illustrates an example embodiment of the UE-mitiated dedicated bearer activation that may be used or performed as described herein. As shown in FIG. 10, in one embodiment, the UE may request a dedicated bearer when a bearer may be used with certain QoS. The UE may include the LBI (e.g. default bearer "Linked Bearer Identity") in a

NAS:BEARER RESOURCE ALLOCATION REQUEST to inform the network (e.g. one or more of the MME/SGW/PGW) that the dedicated bearer may be associated with the LBI of the PDN connection. The LIE initiated dedicated bearer activation shown in FIG, 10 may be performed (e.g. assuming an RRC connection exists between the UE and the eNB2).

[0080] The UE may send to the eNB2 a NAS :BEARER RESOURCE ALLOCATION REQUEST with parameters for the desired QoS. The UE may include the default bearer id/LBD:id5 that may have been created, for example, during the attach procedure. By using the default bearer id LBI:id5, the UE may indicate that the requested dedicated bearer may bebe associated with default bearer idS/PDN connection.

[0081] In an example embodiment, responsive to the NAS :BE ARER RESOURCE

ALLOCATION REQUEST, the eNB2 may forward to the MME the NAS: BEARER

RESOURCE ALLOCATION REQUEST) in a S 1 AP:INITIAL UE MESSAGE. Additionally, responsive to the SIAPTN !TIAL UE MESSAGE, the MME may initiate a dedicated bearer activation procedure with the SGW, by sending, via a SI 1 interface, a Bearer Resource

Command. The MME may include a LBI (a Linked EPS Bearer Id) that may have been received from NAS:BEARER RESOURCE ALLOCATION REQUEST.

[0082] Additionally, the SGW may send a Bearer Resource Command to the PGW, via a S5 interface, to prepare the PGW for a dedicated bearer activation procedure. The SGW may include the LBI. In an embodiment, the PGW may also send a Create Bearer Request to the SOW via a 85 interface and may include in the request the LBI that may have been received from such Bearer Resource Command the EPS bearer id:0, the PGW S5-U, and/or the

PGW__TEID. By sending EPS bearer id:0, the PGW may indicate and may expect or request the MME to assign proper bearer id. Additionally, the SGW may send the Create Bearer Request to the MME, via a SI 1 interface and may include in the request the LBI that may have been received from the Bearer Resource Command, the EPS bearer idiO, the Sl-U and the SGW TEID (SGW_TEID2). By sending EPS bearer id:0, the SGW may indicate and may expect or request the MME to assign proper bearer id.

[0083] The MME may identify an unused bearer (e.g. id:6), and may send to the eNB2 a S1AP:E-RAB SETUP REQUEST including a NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST. The S1AP:E-RAB SETUP REQUEST may include the bearer id:6, the QoS, and the SGW Sl-U TEID (SGW_TEID2) for the bearer. The dedicated bearer may have the same IP address as the default bearer of such a PDN connection (e.g., IP address I in FIG. 5). The eNB2 may set up the EPS bearer id:6 and may forward to the UE a NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST having the bearer id:6.

[0084] According to an embodiment, after establishing the bearer on the eNB2, the eNB2 may send a SI AP:E-RAB SETUP RESPONSE to the MME. Such a S1AP:E-RAB SETUP RESPONSE may include the bearer id:6 and/or the MME Sl-U IP address and TEID

(eNB2_TEID l). The S1AP:E-RAB SETUP RESPONSE may also include the list of bearers that may have been successfully setup on eNB2.

[0085] The UE may establish the dedicated bearer and may send a NAS: ACTIVATE

DEDICATED EPS BEARER CONTEXT ACCEPT having bearer id:6 to the eNB2. The eNB2, in turn, may send a SI AP:UPLINK NAS TRANSPORT message to the MME. The

SIAP:UPLINK NAS TRANSPORT message may mclude a NAS : ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT and the bearer id:6.

[0086] The MME may then send a Create Bearer Response having bearer id:6 to the SGW via a SI 1 interface. The MME may include the eNB2 Sl-U IP address, eNB2_ TElDl and LBI (e.g. default bearer) in the Create Bearer Response. The SGW may send the Create Bearer Response including bearer id:6 to the PGW via a S5 interface. The SGW may include the LBI (e.g. default bearer) in the Create Bearer Response. [0087] For UL user plane data, the eNB2 may send such UL user data to the SOW on the Sl- U using the SGW IP address and SGW TEID2. For DL user plane data, the SGW may send such DL user data to the eNB2 on the Sl-U using eNB2 IP address and eNB2_TEIDl .

[0088] As such, in example embodiments, a NAS: BEARER RESOURCE ALLOCATION REQUEST may be included in a S1 -AP INITIAL UE MESSAGE on secondary eNB (e.g.

eNB2), Additionally, the MME may receive request for Dedicated Bearer from an eNB (e.g. eNB2), with a request to link this Dedicated Bearer with a Default Bearer that may have been set up via a different eNB (e.g. eNBl). Current 3GPP procedures may cause the MME to get confused and possibly reject such a request. According to embodiments herein, the MME receives such a request (e.g. does not reject it) and may associate the Default and Dedicated Bearers from two physically different eNBs.

[0089] According to embodiments, additoinal procedures and/or methods may be provided, performed, and/or used including PGW-Initiated Dedicated Bearer Activation, UE initiated Dedicated Bearer Modification, PGW-initiated Dedicated Bearer modification, UE initiated Dedicated Bearer Deactivation, PGW-Initiated Dedicated Bearer Deactivation, and the like may also be provided and/or used (e.g. as shown in FIGs 1 1-15).

[0090] Additionally, PDN connection procedures and/or methods may be provided, performed, and/or used. For example, procedures and/or methods for distributing default bearers of multiple PDNs across multiple (H)eNBs may be provided, used, and/or performed, in an embodiment, the default bearers of multiple PDNs may be distributed across multiple (H)eNBs by performing an attach procedure followed by a UE initiated PDN connect procedure.

[0091] Additionally, a UE initiated PDN connection may be established (e.g. via a procedure and/or methods). For example, as shown in FIG. 16, a UE-initiated PDN connection may be performed . In one embodiment, the default bearers of the PDN connections may have the different IP addresses and different bearer ids.

[0092] For example, the UE may request a standalone PDN Connection when the UE may want a connection to a different PDN. A new IP address may be assigned by the PGW for the new PDN connection. The UE-initiated PDN connection shown in FIG. 16 may assume an RRC connection may exist between the UE and the eNB2. In one embodiment, the UE-initiated PDN connection is carried out after an attach procedure may be performed using the eNBl , for example. The attach procedure performed using the eNBl may be carried out as described above. [0093] The UE may also send to the eNB2 a NAS :PDN CONNECTIVITY REQUEST. The NAS:PDN CONNECTIVITY REQUEST may include PDN type and APN (Access Point Name) parameters, for example.

[0094] According to an example embodiment, responsive to the NAS:PDN

CONNECTIVITY REQUEST, the eNB2 and the MME may establish the eNB2-MME logical SI -connection and may forward the PDN CONNECTIVITY REQUEST to the MME in a S1AP:IN1TIAL UE MESSAGE. The MME may initiate the PDN connection procedure described herein with the SGW responsive to the S1AP: INITIAL UE MESSAGE by sending a Create Session Request via a SI 1 interface. The MME may identity an unused bearer id (in this embodiment, for example, bearer id: 6)) and may send across the S I 1 interface a Create Session Request. A new UE IP address may then be assigned for the PDN.

[0095] The SGW may send the Create Session Request to the PGW, via the S5 interface, to prepare the PGW for PDN connection procedure. The PGW, in turn, may send the Create Session Response to SGW via the S5 interface. Such a S5:Create Session Response may include the bearer id:6, PGW control and user plane address, TEIDs, UL TFT(Upiink Traffic Flow- Template), a new IP address for the newly created PDN connection, and the like.

[0096] The SGW may send a Create Session Response to MME via the S 11 interface. Such a SI 1 :Create Session Response may include the PGW control and data plane IP address along with TEIDs, S I 1 Control IP and TEID, SGW side of Sl-U IP and TEID (SGW__TEID2) a bearer id, and the like. The SGW may create a bearer (e.g. EPS bearer) context with UL TFT and, if appropriate, the new I P address that may be assigned to UE.

[0097] The MME may send a S 1AP:E-RAB SETUP REQUEST to the eNB2. The S 1 AP:E- RAB SETUP REQUEST may include a NAS: ACTIVATE DEFAULT EPS BEARER

CONTEXT REQUEST. The S1AP:E-RAB SETUP REQUEST may include the bearer id:6, QoS, and SGW Sl-U TEID (SGW_TEID2) for this bearer. The default bearer of the new PDN connection has a different IP address that the default bearer of the existing PDN connection.

[0098] The eNB2 may set up the EPS bearer id:6 and may forward to the UE the

NAS: ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST). After establishing the bearer on the eNB2, the eNB2 may send a S1AP:E-RAB SETUP RESPONSE to the MME. The S1AP:E-RAB SETUP RESPONSE may include the bearer id:6 and the eNB2 Sl-U I and TEID (eNB2_TEID l). The S1AP:E-RAB SETUP RESPONSE may also include a list of bearers that may have been successfully setup on the eNB2.

[0099] The UE may establish the bearer and may send to the eNB2 a NAS: ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT. Such a NAS : ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT may carry the bearer id:6. The eNB2 may send to the MME a SIAP:UPLLNK NAS TRANSPORT message. The SIAP:UPLINK NAS TRANSPORT message may include the NAS: ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT and the bearer id:6.

[0100] The MME may also send to the SGW across the SI 1 interface a Modify Bearer Request. Such a SI 1 Modify Bearer Request may include the bearer id:6. The MME may also include the eNB2 Sl-U IP and eNB2 TEIDl in the SI 1 Modify Bearer Request. The SGW may send the Modify Bearer Response to the MME across the SI 1 interface, for example, after storing the eNB2 S 1 -U IP and eNB2 TEID 1. According to an embodiment, the S 11 Modify Bearer Response may include the bearer id:6.

[0101] For UL user plane data, the eNB2 may send such UL user data to the SGW on the Sl- U using the SGW IP address and the SGW_TEID2. For the DL user plane data, the SGW may send such DL user data to the eNB2 on the Sl-U using the eNB2 IP address and eNB2__TEIDl .

[0102] In an embodiment, a UE-mitiated PDN disconnect may also be provided and/or used. For example, as shown in FIG. 17, a UE-initiated PDN disconnect may be performed. In one embodiment, the default bearers of the PDN connections may have different IP addresses and different bearer ids.

[0103] The UE may initiate the LIE -initiated PDN disconnect, for example, to release a PDN connection it may no longer be using (e.g. it may no longer need). The UE-initiated PD disconnect shown in FIG. 17, assumes an RRC connection exists between the UE and the eNB2. In one embodiment, the UE-initiated PDN connection disconnect is carried out after an attach procedure is performed using the eNBl . The attach procedure performed using the eNB l may be carried out as described above.

[0104] In one embodiment, the UE-initiated PDN disconnect may be earned out after an attach procedure may be performed using the eNBl and a UE-initiated PDN connection may be performed using the eNB2. The attach procedure performed using the eNBl may be carried out as described above, and the UE -initiated PDN connection on the eNB2 may be carried out as using the UE-imtiated PDN connection as described above.

[0105] For example, the UE may send to the eNB2 a NAS :PDN DISCONNECT REQUEST. The NAS: PDN DISCONNECT REQUEST may include the LBI and the EBl. If or when a SI logical connection may already exists between the eNB2 and MME, the NAS: DN

DISCONNECT REQUEST may be forwarded in to the MME in a SiAPUPLINK NAS

TRANSPORT message.

[0106] The MME may initiate the PDN disconnect procedure with SGW, by sending across the SI 1 interface a Delete Session Request. The MME may include the LBI of the PDN connection in the SI 1 :Delete Session Request.

[0107] The SGW, in turn, may send the Delete Session Request to PGW, via the 85 interface, to prepare the PGW for PDN disconnect procedure. After deleting the PDN

connection, the PGW may send the Delete Session Response to SGW via the S5 interface.

Similarly, the SGW may send the Delete Session Response to MME, via the SI 1 interface, after deleting the PDN connection.

[0108] The M ME, in turn, may send a S I A P: E-RAB RELEASE COMMAND to the eNB2. Such a S1AP:E-RAB RELEASE COMMAND may include a N AS DEACTIVATE EPS

BEARER CONTEXT REQUEST. The SI AP:E-RAB RELEASE COMMAND may also include a list of EPS bearer IDs that may belong to the PDN , including the EBI:6 for the standalone PDN connection.

[0109] The eNB2 may release the bearer of the PDN connection and may forward to the UE the NAS DEACTIVATE EPS BEARER CONTEXT REQUEST. After releasing the bearer on the eNB2, the eNB2 may send a SI AP:E-RAB RELEASE RESPONSE to the M ME. The SIAP:E-RAB RELEASE RESPONSE may include the bearer id:6 and/or a list of bearers that may have been successfully released on eNB2.

[01 10] The UE may release the bearer and may send a N AS DEACTIV ATE EPS BEARER CONTEXT ACCEPT to the eNB2. The NAS : DEACTIVATE EPS BEARER CONTEXT ACCEPT may mclude the bearer id:6. The eNB2 may send a SIAPUPLINK NAS

TRANSPORT message to the MME. The SIAP PLINK NAS TRANSPORT message may include the NAS:DEACTIVATE EPS BEARER CONTEXT ACCEPT and/or the bearer id:6. [0111] In example embodiments, a PGW-initiated PDN disconnect (e.g. as shown in FIG. 18) may be provided, performed, and/or used.

[01 12] Detach procedures or methods may be provided, performed, and/or used. For example, as shown in FIG. 19, a UE -initiated detach is performed. In one embodiment, the default bearers of the multiple PDN connections may have the different IP addresses and different bearer ids. The UE may initiate the detach request to cause the UE to de-register from the network. The UE-initiated detach shown in FIG. 19 may assume an RRC connection may exist between the UE and the eNB2.

[0113] In one embodiment, the UE-initiated detach may be carried out after an attach procedure may be performed using the eNB l and a UE-initiated dedicated bearer activation may be performed using the eNB2. The attach procedure performed using the eNBl may be carried out as described above, and the UE-initiated dedicated bearer activation on the eNB2 may be earned out using UE-initiated dedicated bearer activation as described above.

[0114] The UE may send a NAS :DETACH REQUEST to eNB 1 . if or when a S 1 logical connection may exist between the eNBl and MME, the NAS: DETACH REQUEST may be forwarded in SI AP: UPLINK NAS TRANSPORT. Responsive to the SI AP: UPLINK NAS TRANSPORT, the MME may initiate the detach procedure with SGW, for example, by sending a Delete Session Request across the SI 1 interface. The MME may include LB I of the PDN connection in the SI 1 :Delete Session Request. If the UE may have more than one PDN connection, for each PDN connection, the MME may send across the SI 1 interface

corresponding Delete Session Requests.

[0115] The SGW may send the Delete Session Request to PGW, via the S5 interface, to delete the PDN connection. After deleting the PDN connection, the PGW may send a Delete Session Response across the S5 interface to the SGW. The SGW, for example, after deleting the PDN connection, may send the Delete Session Response across SI 1 interface to MME.

[01 16] The MME may then send a S 1 AP:DOWNLINK NAS TRANSPORT message to the eNBl . This SI AP:DOWNLINK NAS TRANSPORT message may include a NAS:DETACH ACCEPT. The MME may also send a S1AP:UE CONTEXT RELEASE COMMAND to eNBl and eNB2 to tear down both the SI -MME logical connections. In embodiments, RRC connections from the UE to eNBl and eNB2 may be released as well, for example, after receiving RRC ConnectionRelease from the eNBl and eNB2. [0117] The eNBl may release the bearers related to the UE, may send a S1AP:UE CONTEXT RELEASE COMPLETE to the MME, and may tear down the SI -MME logical connection from eNBl standpoint. The eNB2 may release the bearers related to the UE, may send a SIAPUE CONTEXT RELEASE COMPLETE to the MME, and may tear down the Sl- MME logical connection from eNB2 standpoint. The MM E may then free up both the SI -MME logical connections on or from its end.

[01 1 8] in an example embodiment, as the Sl -U tunnels may be released at the eNBl and eNB2, UL user plane traffic may not be sent across. Additionally, as the Sl-U tunnels may be released at the eNBl and eNB2, DL user plane traffic may not be sent across.

[0119] A PGW-initiated Detach may also be performed. For example, as shown in FIG. 20, a PGW-initiated detach is performed. In one embodiment, the default bearers of the multiple PDN connections may have the different IP addresses and different bearer ids. In one

embodiment, the default and dedicated bearers of the PDN connection may have the same IP addresses, but different bearer ids,

[0120] The PGW may initiate the detach to trigger or may otherwise cause the UE to de- register from the network. The PGW-initiated detach shown in FIG. 20 may assume an RRC connection may exist between the UE and the eNB2.

[0121] In one embodiment, the PGW-initiated detach may be carried out after an attach procedure may be performed using the eNBl , and a UE-initiated dedicated bearer activation may be performed using the eNB2. The attach procedure performed using the eNBl may be carried out as described above, and the UE-initiated dedicated bearer activation on the eNB2 may be earned out as using UE-initiated dedicated bearer activation as described above.

[0122] The PGW may send a Delete Bearer Request to the SGW via the 85 interface. Such a S5:Delete Bearer Request may include the LBL5 to cause deletion of the PDN connection. When the default bearer and dedicated bearers may belong to the same PDN connection, the PGW detach may be triggered as a result of the S5:Delete Bearer Request including the LBI:5.

[0123] The SGW may send the Delete Bearer Request to MME via the S5 interface. Such a S5:Delete Bearer Request may include the LBI:5 as well. If or when the SGW may include LBI:5, the PDN comiection may be deleted. When default bearer and dedicated bearers belong to the same PDN connection, detach may be triggered as a result of the S5: Delete Bearer Request including the LBL5. [0124] The MME may send a S 1AP:D0WNLIN NAS TRANSPORT message to the eNBl . The S1AP:D0W LIN NAS TRANSPORT message may include a NAS: DETACH REQUEST. The eNBl may then send the NAS: DETACH REQUEST to the UE. The UE may send a NAS: DETACH ACCEPT to eNBl . The eNBl may send a SI AP:UPLIN NAS

TRANSPORT message to the MM E. Such a SI AP:UPL1NK NAS TRANSPORT message may include the NAS:DETACH ACCEPT. The MME may send a Delete Bearer Response to the SGW across the Sl l interface. The SGW may the Delete Bearer Response to the PGW via the Sl l interface,

[0125] The MME may send a S 1 AP:UE CONTEXT RELEASE COMMAND to the eNBl and eNB2 to tear down both the S 1-MME logical connections. In example embodiments, RRC connections from the UE to eNBl and eNB2 may be released, for example, after receiving RRC Connection Release messages from the eNBl and eNB2.

[0126] The eNBl may release the bearers related to the UE, may send a S1AP:UE

CONTEXT RELEASE COMPLETE to the ME, and may tear down the S -MME connection from eNBl standpoint. The eNB2 may release the bearers related to the UE, send a SI AP:UE CONTEXT RELEASE COMPLETE to the MME, and tear down the SI -MME connection from eNB2 standpoint. The MME may then free up both the S I -MME connections from its end.

[0127] In embodiments, as the Sl-U tunnels may be released at the eNBl and eNB2, UL user plane traffic may not be sent across the UL. As all the Sl-U tunnels are released at the eNBl and eNB2, DL user plane traffic may not be sent across the DL, as well.

[0128] FIG. 21 is a block diagram illustrating another example system 40 in which IP flow management may be performed. The system 40 may include a large number of elements that may or may not be shown in FIG. 21. Details of example architecture of a system and its associated elements may be described with reference to FIGs. 84A-84E. According to an embodiment, the system 40 may be described with reference to mobile wireless broadband standard LTE and its associated EPS architecture. The system 40 of FIG. 21 may be similar to the system 10 of FIG. I .

[0129] As shown in FIG. 21, the system 40 may include a bandwidth management controller (BWMC) that may be placed or positioned between the (H)eNBs and the MME. A BWMC SI- MME link may be established between each of the (FI)eNBs and the BWMC. Muitiple (FI)eNBs may connect to a single BWMC. A SI -MME link may be established between the BWMC and the MME. For the MME, the BWMC may operate as an eNB, hiding, for example, the details of (H)eNBs. The BWMC may be a network function between multiple (H)eNBs (e.g. the eNB, and eNB2) and the MME in a network such as an LTE network. The BWMC may receive control messages from different (H)eNBs and may forward them to the MME and vice versa. The BWMC may receive user plane traffic from different (H)eNBs and may forward them to a SGW and vice versa. The UE may make use of the available interfaces for uplink and/or downlink traffic with the help of the BWMC. The BW MC may intelligently route the control messages and user plane traffic.

[0130] F G. 22 is a block diagram illustrating another example system 50 in which IP flow management may be performed. Similar to the system 40 of FIG. 21 , the system 50 of FIG. 22 may include the BWMC. In this embodiment, the eNBl and eNB2 may establish the S I -U directly with the SGW instead of indirectly via the BWMC of the system 40 of FIG. 21.

[0131] FIG, 23 is a block diagram illustrating alternative example system 60 in which IP flow management may be performed. The system 60 of FIG. 23 may be similar to the system 50 of FIG. 22, except as described herein. As shown in FIG. 23, the eNBl and eNB2 may be replaced by two home eNBs (HeNBs) such as HeNBI and HeNB2, A lso, the system 50 may include a HeNB-GW communicatively coupled between the HeNBI and HeNB2 and a SGW.

[0132] The HeNB-GW may be configured to be communicatively coupled with one or more of the following: the MME using the S I -MME interface, the SGW using a corresponding Sl -U interface, andthe HeNBI and HeNB2 using respective Sl-U interfaces and respective S I -MME interfaces. The S I - ME and S l -U interfaces, protocol stacks and elements thereof may be defined in accordance with LTE (e.g. as currently promulgated) along with appropriate changes, modifications and/or the like thereto d sclosed herein.

[0133] FIG. 25 is a block diagram illustrating a portion of a system 70 and certain connections between elements of the system 70. The three physical S I connections may be shown in FIG. 25 including eNBl -BWMC, eNB2-BWMC and BWMC-MME. Also shown may be four logical SI -connections such as an eNBl -BWMC logical S I -connection 1 , which may be identified by eNBl UE S IAP IDl , BWMC UE S IAP IDl identities; a BWMC-MME logical S l- connection 1 , which may be identified by BWMC UE S IAP ID2, MME UE SIAP IDl identities; a eNB2-BWMC logical Sl-connection 1 , which may be identified by eNB2 UE SIAP IDL BWMC UE SIAP ID3 identities; and a BWMC-MME logical SI -connection 2 , which may be identified by BWMC UE SIAP ID4, MME UE SIAP ID2 identities,

[0134] According to example embodiments, BWMC functions may be provided and/or used. For example, the BWMC described herein may include functions for an Attach/Registration procedure on multiple interfaces; a Detaeh/DeRegistration procedure on multiple interfaces; a PDN connectivity request on multiple interfaces; Uplink traffic on multiple interfaces; Downlink traffic on multiple interfaces; Capability to have default and dedicated bearers of a PDN across (H)eNBs; load balancing (e.g..-Distribution of dedicated bearers across (H)eNBs); Faiiover (e.g., re-establish bearers on available interfaces during unavailability of an interface); Mapping between (H)eNB TEID and SG W TEID for user plane traffic; Hiding (H)eNB details, and acting as if BWMC may be sending control and/or user plane messages to MM E/SGW.

[0135] For example, the BWMC may provide Uplink traffic on multiple interfaces. In one embodiment, a UE may send across user plane traffic on multiple bearers that may have been created. The (H)eNB may use TEID of BWMC for the bearer to send the user plane traffic (e.g. uplink). The BWMC may replace the TEID with the SGW TEID and may send across to the SGW.

[0136] Additionally, the BWMC may provide Downlink traffic on multiple interfaces. For exampl e, a SGW may use TEID of BWMC for the bearer to send the user plane traffic (e.g. downlink). The BWMC may replace TEID with (H)eNB TEID.

[0137] The BWMC may also include the capability to have default and/or dedicated bearers of a PDN across (H)eNBs. For example, the BWMC may distribute default and/or dedicated bearers of a PDN across (H)eNBs. The BWMC may maintain a list of bearer ids of a PDN. During detach, for example, if a default bearer of a PDN may be released. The BWMC may release the dedicated bearers of the PDN (e.g. even if those bearers may be spread across (H)eNBs).

[0138] In embodiments, the BWMC may also include load balancing including distribution Of dedicated bearers across (H)ENBs. For example, the BWMC may distribute the dedicated bearers of a PDN across (H)eNBs based on a load. According to an embodiment, the BWMC may select lightly loaded (H)eNB to establish a dedicated bearer. With such an approach, The BWMC' may use each of the interfaces available to a UE. [0139] The BWMC may further include a failover that may, for example, re-establish bearers on available interfaces during unavailability of an interface. The BWMC may re-establish the bearers on an available (H)eNB, if it may notice that a (H)eNB may be down. After establishing the bearers, if user plane traffic may be pending at the BWMC, it may route the traffic accordingly on newly established bearers,

[0140] Additionally, in an embodiment, the BWMC may provide mapping between (H)eNB TEIDs and SGW TEIDs for user plane traffic. During the bearer creation, the BWMC may extract (H)eNB TEID and SGW TEID information from the Sl-MME control messages and may maintain a map((H)eNB TEID <--> BWMC TEID <--> SGW-TEID). The (e)eNB may forward the user plane traffic by including B WMC TEID. After receiving the message, the B WMC may then replace the BWMC TEID with SGW TEID and may send across the data to SGW, The same procedure may apply for the user plane traffic from SGW to (H)eNB.

The BWMC may also hide (H)eNB details and may act as if the BWMC may be sending control and/or user plane messages to a E and/or SGW''. For example, (H)eNB details may be hidden to the MME. The MME may assume the BWMC may be at the other end of Sl -MME. As such, the control messages may pass through the BWMC and the BWMC may ensure to route the messages properly to the respective (H)eNBs. When a message may be received, the BWMC may determine (e.g. check) if it may be a control message or user plane traffic. Control messages may be sent to the MME on a Sl-MME interface and the user plane traffic may be sent across to the SGW on the Sl-U link. The BMWC may be described in more detail below.

[0141] Message sequences may be provided based on the systems described herein. For example, the methods or procedures described herein and the corresponding message sequence charts (e.g. shown in FIGs. 29-43) may be extended extend to the embodiments herein. The methods or procedures include procedures for UE/PGW initiated Attach/Detach,

Default/Dedicated Bearer Activation/Modifieation/Deaetivation, PDN Connect/Disconnect, and the like.

[0142] In an embodiment, an attach procedure that may include new messages introduced herein may be provided, performed, and/or used. For example, an attach on multiple (H)eNBs as well as other procedures on multiple (H)eNBs (e.g. as shown in FIG. 42 and 43) may be performed. In such an embodiment, a LIE may try to send across two different ATTACH REQUESTS to different (H)eNBs at the same time. The BWMC may enable the first ATTACH REQUEST to go up to the ME to register with the MME network. According to an example embodiment, the secondary ATTACH REQUESTS may be suppressed by the BWMC and may not be forwarded to the M ME. The BWMC may establish BWMC S I -MME connections to the (H)eNBs that may have forwarded the secondary ATTACH R EQUESTS to the BWMC.

[0143] To register with a network (e.g. an LTE network), the UE constructs, for example, a NAS: ATTACH REQUEST, NAS:PDN CONNECTIV ITY R EQUEST and may send such requests to eNBl on radio interface.

[0144] Since there may not be a SI connection between the eN Bl and BWMC, the eNBl may establish S I connection and may forward , for example, the NAS: ATTACH REQUEST, NAS:PDN CONNECTIVITY REQUEST in a S I AP: INITIAL UE M ESSAGE. Additionally, since there may not be a S I connection between the BWMC and MME, the BWMC may establish a S I connection and may forward, for example, the NAS: ATTACH REQUEST, NAS:PDN CONNECTIVITY REQUEST in a S I ΑΡ: ΙΝΓΠΑΕ UE MESSAGE.

[0145] In an embodiment, the eNB2 may be available to a UE such that the UE may construct a NAS: ATTACH REQUEST, NASrPDN CONNECTIVITY REQUEST and may send such a request across to the eNB2 on a radio interface.

[0146] Since there may not be a SI connection between the eN B2 and BWMC, the eNB2 may establish a SI connection and may forward the NAS: ATTACH REQUEST, NAS:PDN CONNECTIVITY REQUEST in a S LAP: INITIAL UE MESSAGE.

[0147] As the BWMC may have already received the NA S : ATTACH REQU EST,

NAS:PDN CONNECTIVITY REQUEST from the UE on the eNBl interface, the BWMC may- suppress the message and may not forward the message to the MM E.

[0148] In an example embodiment, the BWMC may construct a SIAP:DQWNLINK NAS TRANSPORT and/or NAS: ATTACH A LREADY IN _ PROGRESS and may send such messages across to eNB2. The eNB2 may send across a

NAS :ATTACH_ ALREADY__IN _ PROGRESS to the UE. After receiving the

NAS:ATTACH_ALREADY_IN_PROGRESS , the UE may not expect the secondary ATTACH procedure to complete. [0149] As the MME may receive the NAS :PDN CONNECTIVITY REQUEST, it may create a session with the SGW by sending a SI 1 : Create Session Request with bearer id:5. It may be the MME's responsibility to identify an unused bearer id.

[0150] The SGW may send across a Sl l : Create Session Request to the PGW as a UE IP may have to be assigned. The PGW may allocate an IP address using a DHCP server or local IP address pool. The DHCP server functionality may be collocated on the PGW. If the DHCP server may be external to the PGW, a radius and/or diameter interface may be used.

[0151] In an embodiment, the PGW may create an EPS bearer context for the UE and may send a S5: Create Session Response to SGW with standard parameters. Additionally, the SGW may send a Sl l : Create Session Response to the MME with standard parameters.

[0152] The MME, according to an example embodiment, may send a S1AP:1NITIAL CONTEXT SETUP REQUEST (e.g. a NAS: ATTACH ACCEPT, NAS: ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST) to the BWMC with one or more of the following parameters: AMBR (e.g. from HSS), an EPS bearer ID, QoS Paransm Sl -U IP and

TEID(SGW TEIDI) of the SGW, PDN address information (e.g. from the SGW), a session management configuration (e.g. UL TFT, Radio Bearer Identity, SDF, and the like), and/or any other suitable parameter.

[0153] The BWMC may break a eNBl-SGW tunnel and may create two tunnels (e.g.

eNB 1_TEID 1 -BWMC_TEID 1 , BWMC_TEID2-SGW_TEID 1) such that ne tunnel from the BWMC to eNBl and another tunnel from the BWMC to SGW may be created. In embodiments, it may be the responsibility of the BWMC to create a map between these two tunnels and use the map for the user plane traffic. The BWMC may extract a Sl-U IP and TEID(SGW TEIDl) of the SGW from the S1AP:INITIAL CONTEXT SETUP REQUEST and may store locally on the BWMC. The BWMC may replace a Sl-U IP and TEID(SGW TEIDl) of the SGW with the BWMC's IP address and the BWMC TEIDl values and may send across the modified

S 1AP: INITIAL CONTEXT SETUP REQUEST (NAS: ATTACH ACCEPT, NAS: ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST) to the eNBl .

[0154] In example embodiments, the eNBl may set up the EPS bearer and may forward NAS: ATTACH ACCEPT, NAS: ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST to the UE. [0155] After establishing a bearer on the eNBl, the eNBl may send a S IAPTNTITAL CONTEXT SETUP RESPONSE to the BWMC by including its Sl -U IP and TEID

(eNBl_TEIDl). The S1AP: INITIAL CONTEXT SETUP RESPONSE may have a list of bearers that may have been successfully setup on eNBl ,

[0156] The BWMC may extract the S 1 -U IP and TEID(eNB 1 _TEID I ) of the eNB 1 from the SIAP:INITIAL CONTEXT SETUP RESPONSE and may store such information locally on the BWMC. The BWMC may replace Sl-U IP and TEIDi eNB 1 _TEID 1 ) of eNBl with BWMC's IP address and BWMC TEID2 values and send across the modified S1AP:INITIAL CONTEXT SETUP RESPONSE to MME.

[0157] The UE may establish the bearer and may send across a NAS: ATTACH

COMPLETE, NAS : ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT to the eNBl . The eNBl may then send a S1AP:UPLIN NAS TRANSPORT (NAS : ATTACH COMPLETE, NAS : ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT) message to the BWMC. The BWMC may send across the SI .AP:UPLINK NAS TRANSPORT (NAS: ATTACH

COMPLETE, NAS : ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT) to the MME. In an embodiment, the M E may send across a SI 1 Modify Bearer Request to the SGW and the MME may include the BWMC's S l-U IP and BWMC JEID2 in the message.

[0158] If the SGW may receive user plane DL data from a PGW for the UE, the SGW may buffer the data until it may receive the S I 1 Modify Bearer Request from the MME. After receiving the Sl l Modify Bearer Request, the SGW may send across DL user plane traffic to the BWMC using BWMC's Sl-U IP and TEID2. Additionally, theSGW may send across the Sl l Modify Bearer Response to the MME, for example, after storing the BWMC's Sl-U IP and BWMC TEID2.

[0159] According to an example embodiment, the eNBl may send UL user data to BWMC on Sl-U using BWMC's IP address and BWMC's BMWC TEiDl. BWMC may change IP address to SGW's IP address and TEID to SGW's SGW_TEID1 and may send across the user data to SGW.

[0160] The SGW may send DL user data to BWMC on S 1 -U using BWMC ' s IP address and BWMC's BWMC TEID2. The BWMC may change the IP address to eNBl 's IP address and TEI D to eNBl__TEiDl and may send across the user data to eN Bl . [0161] In example embodiments, new messages may be provided and/or used. A new message may include ATTACH ALREADY IN PROGRESS. For example, when the BWMC may receive a secondary AttachRequest from another (H)eNB or other H(e)NBs, the BWMC may not forward the AttachRequest to the MME. Instead, the BWMC may suppress the attach request, may create a SI connection to the (H)e^'NB, and may include a

NAS:ATTACH_ALREADY_IN_PROGRESS (e.g. a ne NAS message) in

SlAP:DownlinkNASTransport(). After receiving the NAS : ATTAC H_ALREADY_IN_PRO- GRESS, the UE may assume that UE may be already registered with the network. As such the attach method or procedure may be performed with a single (H)eNB or with multiple (H)eNBs, such that BWMC SI -MME connections may be created on secondary (H)eNBs as well.

[0162] According to an embodiment, the BWMC SI -MME may be the interface between the (H)eNB and BWMC that may support BWM. The BWMC SI -MME may be a new interface or may use messages that may be added to the existing SI -MME interface to support BWM.

[0163] Additionally, an ( )e B may have an option configured by an operator to have BWM including a flag bwmcEnableFlag. In an embodiment, if the flag value may be false, an (H)eNB may not contact the BWMC and may follow the normal flow to connect to the MM E directly.

[0164] In embodiments, multiple RRC connections (e.g. with the same or multiple eNBs) may be maintained between a UE and an eNB and/or a base station in parallel (e.g. even after a handover or soft handover and a rel ease of the original connection in favor of a new connection following the handover or soft handover). For example, as shown in FIGs, 43 and 44, a first RRC connection may be established and maintained between the UE and the eNBl and a second RRC connection may be established and maintained between the UE and the eNB2.

Additionally, RRC connections may also be provided between the UE and other components (e.g. RNCs, base stations, and the like) of the network such that the UE may establish and maintain multiple RRC connections at the same time. As such, in example embodiments, multiple RRC connections (e.g. multiple RRC connections with an eNB and/or a RRC connection for each eNB) may be provided such that different tunnels may be established in parallel.

[0165] in example embodiments, the UE, for example, using the multiple RRC connections may simultaneously send and/or receive data, information, messages, requests, and the like to and from multiple base stations or eNBs. Additionally, such RRC connections may be established and/or maintained at a higher l ayer of the network or system such that less coordination between the components may be used, IP flow mobility may be extended (e.g. multiple flows may be provided) using such RRC connections, independent bearers may be separated to exchange packets (e.g. that may be provided or established via such RRC¹ connections), and the like. Such multiple RRC connections may be associated together in a core network (CN) of the communication network. Additionally, the eNBs and RRC¹ connections established therewith may be geographically spaced out (e.g. rather than being co-located) to increase robustness (e.g. improve stability of connections such that at least one connection may^¬ be maintained).

[0166] Systems and methods disclosed herein may provide procedures and/or methods regarding how to establish multiple RRC connections (e.g. between the UE and/or the eNBs or base stations). FIG. 44 is a block diagram illustrating example system in which multiple RRC connections may be established and marinated. For example, in one embodiment, it may be overkill to attach to a cell each time (e.g. create attachment each time). As such, an attach, for example, to eNBs (e.g. to establish multiple RRC connections therewith) may be performed based on requests (e.g. as needed) or based on conditions (e.g. environmental conditions).

[0167] Systems and methods disclosed herein may further provide information to a core network to enable the core network to know^r that there may be multiple entry and exit points (e.g. multiple connections). In an example embodiment, such information may be piggybacked with the multiple RRC connections (e.g. may be provided when establishing such connections). For example, a MME in the core network (or the PGW, H(e)NB~GW, and/or SGW) may receive such information or a message that may include such information that may pro vide an indication of the multiple RRC connections. The MME, in an embodiment, may then update a list of eNBs that may have a connection that may be used to provide coordination in the network of such connections.

[0168] In embodiments, systems and methods disclosed herein may establish a RRC connection to an eNB (e.g. from a UE) and, after such establishment, may attach the UE to the core network (CN) via the eNB, The release attach request to attach to the CN may then be released. At this point, there may not be an IP address assigned. According to example embodiments, a PDF context may be initiated that may provide an indication to connect a packet of the network (e.g. associated with the attach request or in response thereto) such that an IP address may be assigned and communication may be started.

[0169] In additional embodiments, systems and methods disclosed herein may provide a determination (e.g. at an eNB) as to whether to establish or remove (e.g. tear down) a connection based on network connections or a determination on which connection to route (e.g. by the network) data or data flows.

[0170] Additionally, Bandwidth Management (BWM) functionality in the Mobility

Management Entity (MME) of a 3 GPP Evolved Packet Core (EPC) may also be provided as described herein (e.g. with such multiple connections). For example, the exchange of IP packet flows between the EPC and the UE via simultaneous connections to multiple (H)eNB may also be provided. In an embodiment, the exchange of IP packet flows between the UE and the EPC via simultaneous connections to multiple (H)eNBs may be provided using a BWMC "edge" node between the (H)eNBs and the EPC. Additionally, an establishment of EPS-Bearers between the UE and PGW when multiple connections may be established or maintained may be provided as disclosed herein. To enable multiple connections, procedures, methods, and/or components (e.g. a BWM C) may be provided as described herein along with functions of affected network elements including the User Equipment (UE), (Home) evolved NodeB ((H)eNB), Serving Gateway (SGW), Packet Data Network Gateway (PGW), and Home Subscriber Server ( SS).

[0171] Such functions (e.g. along with extensions and modifications to network procedures, messages, and information elements related to RRC, NAS, SI , S5, S6a, and SI 1 protocols) may include, for example, UE establishment of multiple simultaneous RRC connections via different eNBs and associated changes to UE "reachabilty timer" behavior in the MME including an inclusion of "e B Global Address" as part of RRC Connection procedure, a conditional inclusion of "S-TMSI" as part of RRC Connection procedure, a "RRC Connection Update" message as part of RRC Connection procedure, a specification of a NAS "Update eNB List" procedure between the UE and MME, an inclusion of "List of RABs" in SI 1 "Release Access Bearer Request" message from the M ME to SGW to deactivate the subset of RABs for the affected (H)eNB, and the like; an attach and/or detach when simultaneous connections to multiple eNBs may be allowed by a UE capability and subscription including a use a "BWM- flag" as part of subscription information exchanged via a S6a "Location Update" procedure between the MME and HSS during the "Attach" procedure, a use of a S1AP "Initial UE Message" for UE-initiated "Dedicated Bearer Activation" procedure on a secondary eNB where a corresponding default bearer may not exist, a use of multiple S1AP "UE Context Release Command" messages for a "Detatch" procedure when default and dedicated bearers of a PDN connection may be distributed across different (H)eNBs, and the like; and a network initiated service request when UE may be idle on a secondary eNB including a use of a AS "Reestablish Connection Request" message between the MME and UE to initiate a RRC connection on a secondary (H)eNB (e.g. this may eliminate paging when a RRC connection may already exist on a primary eNB). As such, the establishment, maintenance, and release of multiple connections that may enable bandwidth aggregation, load balancing, connection robustness, and the like across multiple H(e)NBs may be provided.

[0172] Additionally, in embodiments, bearer activation procedures may be provided as disclosed herein (e.g. for multiple connections). For example, a U E may be configured to connect to multiple eNBs and may establish parallel EPS-Bearers between the UE and the PGW and may us both the EPS Bearers for IP flow-based communications with a Packet Data Network (PDN) such as the Internet or Operator Sendee Network.

[0173] To perform such bearer activation procedures, the UE may have established RRC connections on multiple eNBs (e.g. the eNBl and eN B2), the UE may be attached to the Core Network and may have established a Default Bearer with the PGW. Additionally, there may be no EPS-Bearer established with the eNB2 such that the UE may not yet communicate with a Packet Data Network (PDN) via the eNB2. In one embodiment, since there may be no EPS- Bearer established between the eNB2 and PGW, there may be no SI AP connection between the eNB2 and SGW. The methods or procedures disclosed herein may first set up such a SIAP connection and then a Dedicated EPS-Bearer via the eNB2. The UE may be enhanced to recognize a dedicated bearer on the eNB2 without a default bearer. Additionally, the PGW may initiate a procedure via the eNBl, but requests that the EPS-Bearer be established via the eNB2. Signaling may also be introduced to indicate in the message to eN B l that a bearer activation may apply to the eNB 2.

[0174] Additionally, one RRC connection may established, for example, via the eNBl . In such an embodiment, methods whereby a PGW initiates the establishment of an RRC connection with eNB2 first, followed by the establishment of a dedicated EPS-Bearer connection via the eNB2 may be provided. The PGW may initiate a procedure via eNBl, but requests that an EPS- Bearer be established via the eNB2. This may trigger the UE to first set up an RRC connection with the eNB2, followed by a procedure to establish an EPS Bearer via the eNB2.

[0175] Methods and/or procedures for bearer modification and deactivation and/or bearer fail-over may also be provided as described herein. To perform such procedures for bearer modification, signaling may be introduced for deactivation of a dedicated bearer between a secondary eNB via a primary eNB (e.g. with a default bearer). Additionally, to perform such procedures for a bearer fail-lover, a MME may recognize that a radio link via the eNB may have failed (e.g. a radio link failure (RLF) may have occurred). When the MME may recognize that the radio link via eNB 2 may have failed, the MME executes a 'lossless' bearer handover, by creating a message on a SI 1 interface between the MME and SGW as described herein.

[0176] Methods and/or procedures for PDN Connectivity Establishment may be established. Such a methods or procedures may set up a default bearer via the eNB2 and an IP connection that may be made to a PDN2 via eNB2. Additionally, sending a NAS:PDN CONNECTIVITY REQUEST in SIAP: INITIAL UE ESSAGE may be used for such methods and/or procedures.

[0177] FIG. 45 depi cts an example embodiment of tunnels associated with bearers of different PDN connections that may be mapped to different PDNs (e.g. via PGWs). As shown in FIG. 45, multiple connections may be established between a UE and eNBs (e.g. eNBl and eNB2). Additionally, default bearers may belong to different PDN connections. In an example embodiment, the default bearers may have different IP addresses. Additionally, a PDN connection! and/or a PDN connection 2 may map to PDN1 and PDN2 via PGW1 and PGW2 respectively. Such bearers may have different bearer ids.

[0178] FIG, 46 depicts an example embodiment of multiple connections for a UE across multiple eNBs. As shown in FIG. 46, a UE may have a first RRC connection with eNBl and a second RRC connection with eNB2. Additionally, there may be physical SI connections such as eNB l -MME and eNB2-MME and logical SI -connections such as eNBl -MME logical Sl- connection I that may be identified by eNBl UE SI AP ID1, MME UE SIAP ID1 and eNB2- MME logical S 1 -connection 1 that may be identified by eNB2 UE S IAP ID1, MME UE SIAP ID2, for example, between the eNBs and a MME.

[0179] The systems and methods disclosed herein may provide, perform, and/or use an attach and/or registration procedures when multiple RRC connections may be established (e.g. may exist), a dedicated bearer activation, modification, and/or deactivation on multiple interfaces or connections, sendee request procedures, bearer mobility or IP flow mobility (IFOM), PDN disconnect procedures or methods on multiple interfaces or connections, a S 1 release, a detach or de-registration procedure or method, and the like. For example, in addition to the BW -MME functions described above such as capability to have default and/or dedicated bearers of a PDN across (H)eNBs, load balancing including distribution of dedicated bearers across (H)eNBs, PDN connectivity requests on multiple interfaces; uplink traffic on multiple interfaces, downlink traffic on multiple interfaces, failover including re-establishing bearers on available interfaces during unavailability of an interface, an attach and/or registration procedures when multiple RRC connections may be established (e.g. may exist), a dedicated bearer activation, modification, and/or deactivation on multiple interfaces or connections, service request procedures, bearer mobility or IP flow mobility (IFOM), PDN disconnect procedures or methods on multiple interfaces or connections, a SI release, a detach or de-registration procedure or method, and the like may be provided, performed, and/or used.

[0180] In an embodiment, the attach and/or registration procedure or method (e.g. when multiple RRC connections may be established) may be used to register a UE with an EPC network. For example, currently, the UE may have zero or one RRC connection. The procedures or methods disclosed herein may be used to establish multipie RRC connections per UE, such that UE may choose or select an RRC connection or interface to send across

NAS: ATTACH REQUEST, NAS:PDN CONNECTIVITY REQUEST to (H)eNB when multiple (H)eNBs may be available. In an example embodiment, the (H)eNB may create a Sl-MME logical connection with a MME and may send across NAS: ATTACH REQUEST, NAS: PDN CONNECTIVITY REQUEST to the MME. The S1 -U tunnel may then be established from the (H)eNB to SGW for the default bearer.

[0181] After establishing RRC connections with available (H)eNBs, the UE may send across a NAS: ATTACH REQUEST, NASrPDN CONNECTIVITY REQUEST on one RRC interfacef connecting to an (H)eNB) to register with the network. After the registration and/or attach procedure may be completed or done, the UE may send across a NAS: PDN CONNECTIVITY REQUEST OR NAS :BE ARER RESOURCE ALLOCATION REQUEST on other RRC interfaces or connection to use secondary (H)eNBs. [0182] As described above, dedicated bearer activation, modification, and/7or deactivation on multiple interfaces or connections (e.g. multiple RRC connections) may be provided, performed, and/or used. For example, a dedicated bearer activation may be sent across on the available (H)eNBs.

[0183] Such an activation may be sent when initiated by the UE or NW( etwork). In an embodiment, UE initiated dedicated bearer modification and/or deactivation may be sent across on the available (H)eNBs. The MME may send across the downlink S1AP messages to the respective (H)eNB where the bearer may have been setup. Additionally, when a network may initiate dedicated bearer modification and/or deactivation, the MME may send across the downlink S I AP messages to the respective (H)eNB where the bearer may have been setup.

[0184] In embodiments, service request procedures or methods may be provided, performed, and/or used. For example, currently in 3 GPP LTE, a PAGING procedure may be used by the MME, to bring a UE back into the LTE network. In embodiments, with a NAS: NAS:

REESTABLISH CONN REQUEST^' disclosed herein, the MME may bring the UE back into the LTE network on a particular RRC/S1-MME interface. The MME may send across a NAS:

REESTABLISH CONN REQUEST to the UE including a global (H)eNB ID. The UE may reestablish a RRC/S1-MME connection via a specified (H)eNB or specified (H)eNBs.

[0185] Bearer mobility and/or IP flow mobility(IFQM) may be provided, performed, and/or used. For example, currently in 3 GPP LTE, 'Bearer Mobility' and IFOM across multiple (H)eNBs may not be provided (e.g. may not exist). As such, in embodiments described herein, a UE, (H)eNB, and/or MME may initiate a 'Bearer Mobility' procedure or method to move a few bearers from one (H)eNB to another (H)eNB. Additionally, a UE and/or PGW may initiate a 'IFOM' procedure or method to move a few IP flows from one bearer (e.g. a first bearer on (H)eNBl) to another bearer (e.g. a second bearer on (H)eNB2).

[0186] Additionally, as described above, an SI release may be provided, performed, and/or used. When a S 1 release may be performed, for example, the MME may include the bearers that may be setup on a H(eNB) that may have gone down. The MME may include these bearers in SI 1 : Release Access Bearer Request.

[0187] In embodiments, a detach and/or de-registration procedure or method may be provided, performed, and/or used. For example, a detach procedure may be used to de-register UE from the EPC network (e.g. when multiple RRC interfaces ( H(eNB)s) and/or connections thereto may he available to the UE. In a UE initiated detach, the UE may have the option to send a detach request on each (H)eNB that may be connected to MME. The MME may also clean up S I -MME logical connections between (H)eNBs and MME. When a network may initiate a detach (e.g. via a HSS, MME, PGW, SGW, and the like), the MME may send a detach request to the UE on one or more of the (H)eNBs and may eventually clean the all SI -M ME logical connections between the (H)eNBs and MME.

[0188] When default/dedicated bearers of a PDN may be distributed across multiple

(H)eNBs, if a default bearer of a PDN may be released by the UE, MME, SGW, PGW, and the like, the MME may take care of sending a different S1AP:E-RAB RELEASE COMMAND to the respective (H)eNBs and may include respective bearer ids in NAS PDUs. In an example embodiment, the UE may not send multiple detach requests to MME.

[0189] FIG. 47 depicts an example embodiment of procedures and/or methods that may be used herein. For example, FIG. 47 may provide a list of procedures that may supported by a system such as a BWM-M ME and their interaction (e.g. from an LTE standpoint). In

embodiments, "IFOM (IP Flow Mobility)" and "Bearer Mobility" may be additional procedures that may be performed as disclosed herein. Other procedures in the diagram may be modified to support BWM-MME.

[0190] As shown in FIG. 47, multiple RRC connection establishment that may use a BWM- MME(Bandwidth Management - MME)_Attach_Detaeh_ServiceRequest, an attach including UE initiated dedicated bearer activation procedure that may use a BWM~MME(Bandwidth Management - MME)_Attach_Detach_ServiceRequest, a detach that may use a BWM- MME(Band width Management - MME) Attach Detach ServiceRequest, a service request (SR) and procedures thereof that may use a BWM-MM E(Bandwidth Management - MME) Attach Detach ServiceRequest, dedicated bearers (DB) including an attach, dedicated bearer procedures that may use aBWM-MME(Bandwidth Management - MME) Dedicated bearer_PDN, a Packet Data Network(PDN) including PDN connection procedures that may use a BWM-MME(Bandwidth Management - MME)_ Dedicated beare _PDN, IFOM(IP flow mobility) that may use a BWM-MME(Bandwidth Management - MME)_IFOM, bearer mobility that may use a BWM-MME(Baiidwidth Management - MME) IFOM, and the like may be procedures and/or methods that may be performed. [0191] As described above, multiple RRC connections and interfaces may be supported. For example, a primary RRC connection may be established followed by other RRC connections as shown in FIG. 48. In such an embodiment, a UE may establish a RRC connection with eNBl (e.g. a first RRC connection) and may perform the attach procedure. After the attach procedure, the UE may establish the remaining RRC connections with the remaining eNBs (e.g. eNB2 shown in FIG. 48). The UE may then update the MME with the l ist of eNBs that it may be connected to.

[0192] Various messages may be provided and/or used to establish a primary RRC followed by other RRC connections. For example, a RRCConnectionSetup message (e.g.

RRC:RRCConnectionSetup) may be used to establish a SRB1. In an embodiment, a new IE, globaleNBID may be added to RRCConnectionSetup message. Additionally, such a message may also include, provide, and/or use a signaling radio bearer: SRB0, RLC-SAP: TM, logical channel: CCCH, direction: E-UTRAN to UE, and the like.

[0593] An example RRCConnectionSetup message may be as follows:

3N1 STAR

SEQUENCE I cl

rri .orinecoi on se .up --r RC'Connec ionSe -- r 3- IEs

-e6 NULL, spare s NULL , spare-! NULL

jQUENCE {

Radi oResourceCorif i gDec

g loba leNBI D Global eNBID ,

OPT IONAL Need

CHOICE

SIT STRING ( S I ZE ( 20 ) ,

BIT STRING ( S IZE ( 28 ) )

[0194] Additionally, as described above, a NAS: UPDATE ENBLIST REQUEST message may be used to establish a primary RRC connection followed by additional RRC connections. Such a message may be sent by the UE to the network to update the MME with the list of eNBs it may be connected to. The NAS: UPD ATE ENBLIST REQUEST message may include a message type such as UPDATE ENBLIST REQUEST, a significance such as dual, a direction such as UE to network, and the like and/or information in Table 1 .

[0195] A method or procedure for establishing a primary RRC fol lowed by additional RRC connections may be performed as described below. For example, initially, no RRC connection may be established between a UE and eNBs such as eNBI and eNB2. The UE may send across the RRCConnectionRequest to the eNBI, for example, by including a random value. The eNBI may then send across the RRCConnectionSetup to the UE which may include a global ID of the eNB 1. In response to receiving the RRCConnectionSetup, the UE may send across

RRCConnectionSetupComplete to the eNBI . The UE may then finish the attach procedure on the eNBI (e.g. as described above ). In such an embodiment, the UE may or may not include the eNB ID List in NAS: ATTACH REQUEST.

[0196] After finishing the attach procedure on the eNBI , the UE may send across a

RRCConnectionRequest to the eNB2 by including, for example, S-TMSL The eNB2 may send across a RRCConnectionSetup to the UE by including a global ID of the eNB2. In response to receiving the RRCConnetionSetup, the UE may send across a RRCConnectionSetupComplete to the eNB2. The UE may then construct the NAS:UPDATE ENBLIST REQUEST which may include a list of eNBs (e.g. eNBI and eNB2) that it may be connected to and may send such a request and list across to the eNBI in a RRC:ULInforoiationTransfer message.

[0197] According to an example embodiment, the eNBI may then send across the

SIAP:UPLINK NAS TRANSPORT(NAS:UPDATE ENBLIST REQUEST) to the MME such that the MME may send across the SlAPiDOWNLIN NAS TRANSPORT (NAS:UPD ATE ENBLIST ACCEPT) to the eNBL After receiving the SlAPiDOWNLINK NAS

TRANSPQRT(NAS:UPDATE ENBLIST ACCEPT, the eNBl may send across a

RRC:DLInformationTransfer(NAS:UPDATE ENBLIST ACCEPT) to the UE.

[0198] After establishing RRC connections as described above, user plane traffic may be routed. For example, the eNBl may send uplink user plane data (UL) or UL user data to the SGW on the SI -U using SGW's IP address and SGWJFEIDI , Additionally, the SGW may send downlink user plane data (DL) or DL user data to the eNBl on the Sl-U using eNBI 's IP address and eNB^'l_TEIDl .

[0199] In another embodiment, each of the multiple RRC connections may be established at once or at the same time as shown in FIG. 49. In such an embodiment, the UE may establish RRC connections with each of the available eNBs (e.g. the eNBl and eNB2) and may then perform the attach procedure. After completing or finishing the attach procedure, the UE may send across a RRCConneetionUpdate to the eNB2 by, for example, including S-TMSI.

[0200] Various messages may be provided and/or used to establish multiple RRC" connections at once. For example, a RRCConnecdonSetup message (e.g. RC:R CConnectionSetup) may be used to establish a SRBI . In an embodiment, a new IE, globaleNBID may be added to

RRCConnectionSerup message. Additionally, as described above, such a message may also include, provide, and/or use a signaling radio bearer: SRB0, RLC-SAP: TM, logical channel: CCCF, direction: E-UTRAN to UE, and the like.

[0201] An example RRCConnectionSerup message may be as follows:

— ASNlSTAR'j r c-- criu

spare4 NULL,

s ares NULL, spare2 NTT

SEQUENCE {

RadioResourceConfigDedrcated,

globaleNBID GlobaleNBID,

nonCrit calExte sion SEQUENCE { } 31obaieNBID :HO

TRING ( 2 0 ) ,

STRING ( 26 ) )

[0202] Additionally, a RRCConnectionUpdate message may be provided. The

RRCConnectionUpdate message may be used to update eNB with S-TMSI information of the UE, Such a message may also provide, include, and/or use signaling radio bearer: SRB0; RLC SAP: TM; logical channel: CCCH; direction: UE to E-UTRAN; and the like.

[0203 ] An example RRCConnectionUpdate message may be as follows:

RRCConnec t ionUpdate- 8 - IE BQ JENCE_^ {

BQTJENCE {

S-TMS I

ASM STOP

Table 2: RRCConnectionUpdate Information

RRCConnectionUpdate field descriptions j ue-Identity I UE identity included to facilitate contention resolution by lower layers. It may be s-TMSI. i

[0204] A method or procedure for establishing multiple RRC connections at once or at the same time may be performed as described below. For example, initially, no RRC connection between the UE, eNBl , and eNB2 may be established. As such, the UE may may send across a RRCConnectionRequest to the eNBl by includi g a random value. The eNBl may then send across a RRCConnectioiiSetup to the UE which may include a. global ID of the eNBl ,

[0205] After receiving the RRCConectionSetup, the UE may send across

RRCConnectionSetupCompIete to eNBl . The UE may also send across a

RRCConnectionRequest to the eNB2 by including a random value. [0206] The eNB2 may then send across a RRC Connection Setup to UE by including a global ID of the eNB2, In response to receiving the RRCConectionSetup from the eNB2, the UE may send across a RRCConnectionSetupComplete to the eNB2. The UE may finish the attach procedure (e.g. as described herein) on the eNBl . In such an embodiment, the UE may include an eNB ID List in NAS: ATTACH REQUEST. The eNBIDList may have the eNBl , eNB2 global IDs. The UE may send across the RRCConnectionUpdate with S-TMSI to the eNB2.

[0207] After establishing RRC connections as described above, user plane traffic may be routed. For example, the eNBl may send uplink user plane data (UL) or UL user data to the SGW on the S 1 -U using SG W's IP address and SG W_ TEID i . Additionally, the SGW may send downlink user plane data (DL) or DL user data to the eNBl on the Sl-U using eNBl 's IP address and eNB 1 TEID 1.

[0208] In embodiments, a RRC connection release and/or a S 1 release may be provided, performed, and/or used (e.g. as shown in FIG. 50). For example, an eNB (e.g. the eNBl or the eNB2) may start a SI release procedure to release a logical SI -MME connection and EPS bearers at the eNB. The EPS bearers at the MME and SGW may not be released.

[0209] Various messages may be provided/or used to perform such a release. For example, a S 11 :Release Access Bearer Request message (e.g. that may include the information in Table 3) may be provided and/or used. The Release Access Bearers Request message may be sent on the SI 1 interface by the MME to the SGW as part of the SI release procedure. A list of RABs (e.g. ListofRABs) may be sent on SI 1 interface to deactivate EPS bearers. Such bearers may not be released at the SGW, but rater deactivated. Current!)' (e.g. in existing 3GPP LTE), the list of RABs may not be sent on the SI 1 interface. However, as described herein, as the UE connects to multiple e Bs, the MME may inform the SGW to deactivate the bearers that may have been established on the eNB that may have triggered the SI release procedure. Other bearers that may have been established on different eNBs may not be deactivated. Table 3: Information Element (IE) in Release Access Bearers Re uest

[0210] A method or procedure for providing RRC connection release and/or a SI release may be performed as described below. Initially, RRC connections between the UE, eNB! , and eNB2 may be established (e.g. may have already been established as described above). For example, a primary RRC connection followed by other RRC connections may be established to have multiple RRC connections between the UE, eNBl, and eNB2.

[0211] In an embodiment, the eNB2 may send across a Si AP:UE CONTEXT RELEASE REQUEST to the MME during the SI release procedure. The MME may then send across the Sl l :Release Access Bearer Request to the SGW with the list of bearers that may have been activated on eNB2.

[0212] In response thereto, the SGW may send across the Sl l :Release Access Bearer Response to M ME after deactivating the bearers that may have been present in the Sl l :Release Access Bearer Request message . In an embodiment, the SGW may not release these bearers. The SGW may not deactivate the bearers that may have been established other than eNB2. Additionally, the SGW may delete the Sl-U TEID information of the eNB2, but may preserve Sl-U TEID information from the SGW or the standpoint thereo.

[0213] According to an example embodiment, the MME may send across the S 1AP:UE CONTEXT RELEASE COMMAND to the eNB2. The eNB2 may then send across the RRCConnectionRelease to the UE and the eNB2 may release the hearers locally that may have been established for the UE. The eNB2 may send across the S1AP:UE CONTEXT RELEASE COMPLETE to the MME. In response thereto, the MME may not release the bearers and may preserve the UE context. The UE state may be modified to an IDLE mode at the MME.

[0214] After releasing or deactivating an RRC connection (e.g. the eNB2) as described above, user plane traffic may be routed (e.g. via the eNBl). For example, the eNBl may send uplink user plane data (UL) or UL user data to the SGW on the S l -U using SGW's IP address and SGW TEIDL Additionally, the SGW may send downlink user plane data (DL) or DL user data to the eNBl on the S l-U using eNBl 's TP address and eNBl TEIDl .

[0215] In embodiments, an attach and/or a UE initiated dedicated bearer activation procedure or method may be provided, performed, and/or used. For example, an attach and/or registration procedure and a dedicated bearer activation, modification, and/or deactivation on multiple interfaces may be provided and/or performed .

[0216] An example attach procedure or method may be shown in FIG. 51. Various messages may be provided/or used to perform such an attach. For example, a S6a: Update Location Answer may be used. The Subscription-Data AVP in the S6a: Update Location Answer may have BWM-Flag, and set to 0 by default. The BWM-Flag AVP may be of type Unsigned32 and it may include a bit mask. The definition of the bits may be shown in Table 4.

Table 4: BWM-Flag

[0217] As described above, during RRC connection establishment eNB may send across its global eNB ID to the UE. The UE may receive global eNB IDs from different RRC connections estabiished with multiple eNBs. The UE may send across a list of global eNB IDs in a MAS: ATTACH REQU EST during the attach and/or registration procedure.

[0218] For example, a NAS: ATTACH REQUEST(with eNB global IDs list that UE connected to during RRC connection establishment) may also be provided and/or used. Such a message may be sent by the UE to the network in order to perform an attach procedure. The NAS: ATTACH REQUEST may include a message type: ATTACH REQUEST, a significance: dual, a direction: UE to network, and the like and/or information in Table 5.

Table 5: ATTACH REQUEST message content

> Global eNB ID 9.2.1.37 M TBD TBD

[0219] A UE initiated dedicated bearer activation (e.g. as shown in FIG. 52) may be provided, performed, and/or used. For example, the UE may request for a dedicated bearer when a bearer may be used with certain QoS (e.g. as described above). The UE may include LBI(e.g. default bearer) in the NAS: BEARER RESOURCE ALLOCATION REQUEST to inform the network (e.g. MME, SG W, PGW, and the like) that a new dedicated bearer may be associated with the LBI of the PDN connection.

[0220] A method or procedure for performing a UE initiated dedicated bearer activation may be provided (e.g. as shown in FIG. 52 and described at least in part above). Initially, RRC connections between the UE, eNBl , and eNB2 may be established (e.g. may have already been established as described above) or set up. Additionally, there may be no SI logical connection from the eNB2 to the MME and the UE may be already registered with a network such as a LTE network, the UE may send across S-TMSI along with NAS: BEARER RESOURCE

ALLOCATION REQUEST to the eNB2. In an embodiment, as there may be no logical SI connection from the eNB2 to MME for the combination of eNB2, UE, the NAS: BEARER RESOURCE ALLOCATION REQUEST may be forwarded in a SLAP: INITIAL UE

MESSAGE, by including S-TMSI and NAS: BEARER RESOURCE ALLOCATION

REQUEST.

[0221] The M ME (e.g. in addition to initiating the dedicated bearer activation procedure with SGW, by sending the S 11 : Bearer Resource Command described herein) may associate both the SI logical connections of the UE (e.g. eNBl -MME & eNB2~MME) using or based on the S- TMSI.

[0222] The MME may further identify an unused bearer (id:6) and may send across the S1AP: INITIAL CONTEXT SETUP REQUEST (NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST)) to the eNB2. The S1AP: INITIAL CONTEXTSETUP REQUEST may have bearer id:6, Qos, and SGW Sl-U TEID(SGW_TEID2) for such a bearer. The dedicated bearer may have the same IP address of the default bearer of such a PDN connection.

[0223] In an embodiment, after establishing the bearer on the eNB2, it may send the S LAP: INITIAL CONTEXTSETUP RESPONSE, (bearer id: 6) to the MME by including its Sl-U IP and TEID (eNB2_TEIDl). The S IAP: INITIAL CONTEXTSETUP RESPONSE may have the list of bearers that may have been successfully setup on eNB2.

[0224] Detach procedures (e.g. as described herein and above) may be provided, performed, and/or used. An example detach procedure that may be provided, performed, and/or used herein may be shown in FIG. 53. The UE may send across a detach request (e.g. a UE initiated detach) to de-register from the network as described herein. As shown in FIG. 53, SI AP messages may be used to perform the detach (e.g. a UE initiated detach) . For example, default and/or dedicated bearers of a PDN connection may be distributed across the eNBl and eNB2 and, as such, two SIAP: UE CONEXT RELEASE COMMANDS may be used. Additional ly, the MME in such a procedure may include the LBI of the PDN and, if the UE may have more than one PDN connection, for each PDN connection, the M ME may send across a

SI 1 :DeleteSessioiiRequest. In embodiments, the MME may also send across SIAP: UE

CONTEXT RELEASE COMMAND to the eNBl and eNB2 to tear down both the Si -MME logical connections. The RRC connections from the U E to the eNB l and eNB2 may then be released at this point of time, after receiving 'RRC ConnectionRelease' from the eNBl and eNB2.

[0225] Another example detach procedure that may be performed, provided, and/or used herein may include a PGW initiated detach shown in FIG. 54. For example, a PGW may trigger detach procedure in order to detach UE from the network as shown in FIG. 54. In such an embodiment, the MME may send across a SI AP: UE CONTEXT RELEASE COMMA D to the eNBl and eNB2 to tear down both the SI -MME logical connections. The RRC connections from the UE to eNBl and eNB2 may then be released at this point of time, after receiving 'RRC

ConnectionRelease' from the eNBl and eNB2.

[0226] Sendee request (SR) procedures and/or methods may be provided, performed, and/or used. In an example embodiment, a service Request procedure may be either a UE initiated service request or a Network (e.g. SGW) initiated service request. Additionally, there may be no changes herein to the standard UE initiated service request procedure.

[0227] In embodiments, the SGW initiated sendee request may be modified as described herein and shown in FIG. 55 (e.g. where the UE may be in IDLE mode). Additionally, there may be a new scenario or trigger for a PGW initiated dedicated bearer modification to result in sendee request procedure.

[0228] In a SGW initiated sendee request (e.g. where UE may be in IDLE mode), when the SGW may receive downlink data for the UE from the PGW, the SGW may initiate the procedure and/or method, for example, shown in FIG.55. Such a service request procedure may e performed without PAGING. [0229] Various messages may be provided and/or used to perform the SGW mitiated SR. For example, a NAS: REESTABLISH CONN REQUEST may be provided and/or used. Such a message may be sent by the MME and may be used to request the UE to re-establish a connection from the UE to MME(RRC+S1 ). In such an embodiment, as there may be no RRC connection available, from the UE to eN B2, a RRC connection from the UE to eNB2 and S I logical connection from the eNB2 to MME may be re-established. Such a message may include a direction of M ME --> UE and may include the information sho wn in Table 6 below.

[0230] A method or procedure for initiating a SR at a SG W may be performed as described below (e.g. and shown in FIG. 55). Initially, RRC connections between the UE and the eNBl may be established or set up and the UE may be in IDLE mode. Additionally, an attach procedure, a UE initiated dedicated bearer activation procedure and/or default and dedicated bearers of a PDN distributed across (H)eNBs may be performed and/or used.

[0231] In an embodiment, to perform such a SGW initiated SR, the PGW may send downlink data for the UE to SGW. The SGW may send across a SI 1: Downlink Data

Notification to the MME. MME may send across S 11 : Downlink Data Notification

Acknowledge to SGW.

[0232] The MME may send across a S 1AP:D0WNLINK NAS

TRANSPORT (NAS REESTABLISH CONN REQUEST) to the eNBl and may include the eNB global ID in the NAS REESTABLISH CONN REQUEST for which RRC connection status may be IDLE.

[0233] In response thereto, for example, the eNBl may send across NAS REESTABLISH CONN REQUEST to the UE. After receiving the NAS : REESTABLISH CONN REQUEST with the eNB2 information, the UE may establish a RRC connection with the eNB2 and may send across a NASrSERVICE REQUEST to the eNB2.

[0234] The eNB2 may then send across 81 APTNITIAL UE MESS AGE(NAS : SERVICE REQUEST) to the MM E, as there may be no SI logical connection from the eNB2 to the MM E, Additionally, the M ME may send across a SI APTNITLAL CONTEXT SETUP REQUEST^' to the eNB2 with the list of bearers that may be setup. The MME may include the bearers that may have been in INACTIV E mode at the MME. In example embodiments, bearers may have entered into INACTIVE mode when the UE may enter into the IDLE state or mode.

[0235] The eNB2 may perform bearer sync-up with UE and may send across S1AP:1NITIAL CONTEXT SETU P RESPON SE to the MME, The UE may then delete the bearers that may be INACTIVE at UE and may not be in the list received from the eNB2. Additionally, the MM E may send across the SI 1 :Modify Bearer Request to the SGW and the SGW may send acrossthe S I 1 :Modify Bearer Response to the MME.

[0236] After performing a SGW initiated SR, user plane traffic may be routed. For example, the eNB2 may send uplink user plane data (UL) or UL user data to the SGW on S l-U using the SGW's IP address and SGW_TE1D2. Additionally, the SGW may send downlink user plane data (DL) or DL user data to the eNB2 on S l-U using eNB l 's IP address and eNB2_TEIDl .

[0237] As described above, PGW initiated dedicated bearer modification procedure and/or method may be provide, performed, and/or used herein. The PGW initiated dedicated bearer modification procedure may be described below and shown in FIG. 56 where the UE may be in IDLE mode. In an example embodiment, the sendee request procedure or method that may be PGW initiated may be without PAGING.

[0238] A method or procedure for initiating a dedicated bearer modification or SR at a PGW may be performed as described below (e.g. and shown in FIG. 56). Initially, RRC connections between the UE and the eNBl may be established or set up and the UE may be in IDLE mode. Additionally, various messages may be provided and/or used such as NAS: REESTABLISH CONN REQUEST. Such a message may be sent by the MME and may be used to request the UE to re-establish a connection from the UE to the MME(RRC+S 1). In such an embodiment, as there may be no RRC connection available, for example, from the UE to eNB2, an RRC connection from the UE to eNB2 and S I logical connection from the eNB2 to MM E may be re- established. Such a message may include a direction: MME -> UE and the information in Table

[0239] To perform such a PGW initiated procedure, the attach procedure, UE initiated dedicated bearer activation procedure, default and dedicated bearers of a PDN distributed across (H)eNBs that may be provided may be performed and/or used. Additionally, in the PGW initiated SR. the PGW may send a S5 Update Bearer Request to the SGW. The SGW may then send across a SI 1 : Update Bearer Request to the MME.

[0240] The MME, in an embodiment, may send across a S 1 AP : DOWNLINK NAS

TR ANS PO RT(N AS : REESTAB LI SH CONN REQUEST) to the eNBl and may include the eNB global ID in NAS REESTABLISH CONN REQUEST for which RRC connection status may be IDLE.

[0241] In response thereto, the eNBl may send across the NAS:REESTABLISH CONN REQUEST to the UE. After receiving the NAS REESTABLISH CONN REQUEST with the eNB2 information, the UE may establish RRC connection with the eNB2 and may send across a NAS:SERVICE REQUEST to the eNB2.

[0242] The eNB2 may send across a SI AP:IMTIAL UE MESSAGE(NAS:SERVICE REQUEST) to the MME, as there may be no SI logical connection from the eNB2 to the MME. The MME may then send across a S1AP: INITIAL CONTEXT SETUP

REQUEST(NAS : ODIFY EPS BEARER CONTEXT REQUEST) to the eNB2.

[0243] In an embodiment (e.g. in response thereto, the eNB2 may send across a

S1AP:IN ]TIAL CONTEXT SETUP RESPONSE to the MME and a NAS MODIFY EPS BEARER CONTEXT REQUEST to the UE. The UE may then send across the NAS MODIFY EPS BEARER CONTEXT ACCEPT to the eNB2. [0244] After receiving such a message, the eNB2 may send across a S 1AP:UPLINK NAS TRANSPORTi NAS: MODIFY EPS BEARER CONTEXT ACCEPT) to the MME. The MME may send then across the Sl l :Update Bearer Response to the SGW such that the SGW may send across the S5:Udate Bearer Response to the PGW. The MME may also send across the

SI 1 : Modify Bearer Request to the SGW and the SGW may send across the Sl l Modify Bearer Response to the MME.

[0245] After performing a PGW initiated dedicated bearer modification or SR, user plane traffic may be routed. For example, the eNB2 may send uplink user plane data (UL) or UL user data to the SGW on Sl-U using the SGW's IP address and SGW TEID2. Additionally, the SGW may send downlink user plane data (DL) or DL user data to the eNB2 on Sl-U using the eNBl 's IP address and eNB2_TEID ! .

[0246] In an example embodiment, a PG W initiated dedicated bearer activation, for example, on a primary (attached) eNB may be provided, performed, and/or used. FIG. 57 illustrates an example embodiment of a PGW initiated dedicated bearer activation on an eNB (e.g. the eNBl) where attach as described above may be completed or done. The PGW initiated dedicated bearer activation shown in FIG. 57 may include procedures similar to the attach procedure described above along with the default and dedicated bearers of a PDN distributed across (H) PGW initiated dedicated bearer activation (On secondary eNB and RRC may be established with UE) [0247] PGW initiated dedicated bearer activation, for example, on a secondary eNB and RRC connection that may be established with the UE. In such an embodiment (e.g. PGW initiated dedicated bearer, for example, on the secondary eNB and RRC connection), default and dedicated bearers of a PDN connection may have the same IP address and different bearer ids. Such bearers may have the same IP address even if bearers may be spread across different (H)eNBs. The Secondary eNB (e.g. the eNB2) may be the eNB that may be different from the eNB where the attach may have been performed or completed or done.

[0248] In example embodiments, the PGW initiated dedicated bearers activation, for example, on the secondary eNB and RRC connection may use an attach and/or registration procedure as described herein a dedicated bearer activation, modification, and/or deactivation on multiple interfaces, capability to have default and dedicated bearers of a PDN across (H)eNBs load balancing including distribution of dedicated bearers across ( )eNBs, service request, and the like. [0249] The information described herein may be part or used with a network such as an LTE network or system. In an embodiment, each eNB in the network (e.g. the LTE network) may have an identifier (e.g. a Global eNB ID) that may be understood by the UE and MME. When a RRC connection may be established from the UE to an eNB, the eNB may send across this ID to the UE as described herein. According to an embodiment, when the UE may have muitiple RRC connections with eNBs, the LIE may send across a list of eNB IDs in NAS: ATTACH

REQUEST^' to the M ME. The MME may then store the eNB ID and may use them to create MME initiated SI logical connections as described above.

[0250] The PGW may initiate the dedicated bearer activation procedure to establish a dedicated bearer procedure with the UE to push a QoS profile. In such an embodiment, the PGW may mclude LBI(default bearer) in the S5: Create Bearer Request to inform the network (e.g. the MME or SGW) that a new dedicated bearer may be associated with the LBI of the PDN connection.

[0251 ] A method or procedure for initiating a dedicated bearer activation procedure (e.g. on a secondary eNB with a RRC connection established with the UE) at a PGW^T may be performed as described herein (e.g. and shown in FIG. 58). Initially, RRC connections between the UE and the eNBl and the eNB2 may be established or set up. Additionally, the MME may have other eNBs the UE may be connected to and the eNBl and eNB2 may be served by the same SGW.

[0252] In an example embodiment, the eNB2 (e.g. the secondary eNB) may map the UE from S-TMSI received from the MME. After the attach procedure, the UE may update each the eNBs with its S-TMSI. A RRC re-establishment or other RRC procedure with the eNBs other than primary eNB to update eNBs with S-TMSI may be performed.

[0253] Various messages may be provided and/or used to perform a PGW initiated dedicated bearer activation procedure such as a SLAP: INITIAL CONTEXT SETUP SI CONNECT REQUEST or INITIAL CONTEXT SETUP SI CONNECT REQUEST, and the like. Such a message may be sent by the MME to request the setup of a UE context and may include a direction such as MME—> eNB and/or additional information. Table 8

apa ty Subscriber 0 9.2.1 .39 YES Ignore Profile ID for

RAT/Frequenc

y priority

CS Fallback 0 9.2.3.21 YES reject Indicator

SR.VCC 0 9.2.1.58 YES ignore

Operation

Possible

[0254] The PGW may then send across S5: Create Bearer Request to SGW with the LBI , EPS bearer id:0, and/or PGW S5-U PGW TEID. By sending the EPS bearer id:0, the PGW may expect the MME to assign a proper bearer id. Additionally, the SGW may send the SI 1 : Create Bearer Request to the MME, by including LBI ,EPS bearer id:0 and SI-U SGW^T

TE1D(SGW TEID2). By sending the EPS bearer id:0, the SGW may expect the MME to assign a proper bearer id.

[0255] In an embodiment, the MME may identify an unused bearer (id: 6) and maysend across a S 1AP: INITIAL CONTEXT SETUP SI CONNECT REQUEST (NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST) to the eNB2. The MME may have the list of the eNB IDs(Global eNB ID ) the UE may be connected to. The MME may select an eNB from the list that may be served by the SGW that may be sending the SI 1 : Create Bearer Request and may send across the S1AP: INITIAL CONTEXT SETUP Si CONNECT REQUEST (NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST). The MME may create a SI logical connection and may include a MME UE S1AP ID2(MME UE S1AP ID) in the message, as there may be no SI logical connection from the MME to eNB2. The S 1AP: INITIAL

CONTEXT SETUP SI CONNECT REQUEST may have a bearer id:6, Qos, and/or SGW Sl-U TEID(SGW_TEID2) for such a bearer. The dedicated bearer may have the same IP address of the default bearer of such a PDN connection (e.g. as shown in FIG. 46 that may illustrate logical SI -connections for UE across multiple eNBs).

[0256] The eNB2 may identify a unique eNB2 UE S 1 AP ID 1 (eNB UE S I AP ID) for the newly created SI logical connection and may set up the EPS bearer id:6 and may forward NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST, (bearer id: 6), and the like to the I:!;

[0257] After establishing the bearer on the eNB2, it may send a S 1 AP: INITIAL CONTEXT SETUP RESPONSE, (bearer id: 6) ιο the MME by including its Sl-U IP and

TEID(eNB2_TEID 1 ). The SI AP: INITIAL CONTEXT SETUP RESPONSE may have the list of bearers that may have been successfully setup on the eNB2 and newly created eNB2 UE SLAP ID1.

[0258] The UE may establish the bearer and may send across NAS: ACTIVATE

DEDICATED EPS BEARER CONTEXT ACCEPT, (bearer id: 6) to the eNB2, The eNB2 may send the SLAP: UPLINK NAS TRANSPORT (NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT), (bearer id: 6) message to the MME. The MME may send across the 81 1 : Create Bearer Response (bearer id:6) to the SGW. The MME may include eNB2's Sl-U IP and eNB2 TEID1 in the message as well as the LBI(default bearer). The SGW may then send across the S5: Create Bearer Response(bearer id:6) to the PGW. The SGW may include LBI (default bearer) in such a message.

[0259] After performing a PDW initiated dedicated bearer activation (e.g. on a secondary eNB and RRC connection), user plan traffic may be routed. For example, the eNB2 may send uplink user plane data (UL) or UL user data to the SGW on Sl -U using SGW's IP address and 8GW__TEID2. Additionally, the SGW may send downlink user plane data (DL) or DL user data to the eNB 2 on Sl-U using eNB2's IP address and eNB2 TEID1.

[0260] In additional embodiments, a PGW initiated dedicated bearer activation, for example, on a secondary eNB via a primar}_' (attach) eNB where an RRC may be established with the UE may be provided, performed, and/or used (e.g. as shown in FIG. 59). In such an embodiment, default and dedicated bearers of a PDN connection may have the same IP address and different bearer ids. Such bearers may have the same IP address even if they may be spread across different (H)eNBs.

[0261] In example embodiments, the PGW initiated dedicated bearer activation, for example, on the secondary eNB via the primary (attach) eN B with a RRC connection may use an attach and/or registration procedure as described herein, a dedicated bearer activation, modification, and/or deacti vation on multiple interfaces, capability to have default and dedicated bearers of a PDN across (H)eNBs load balancing including distribution of dedicated bearers across (H)eNBs, sendee request, and the like.

[0262] The PGW may initiate a dedicated bearer activation procedure to establish a dedicated bearer procedure with the UE to push a QoS profile. The PGW may include the LB I(default bearer) in the S5:Create Bearer Request to inform the network (e.g. the MME or SGW) that the new dedicated bearer may be associated with the LBI of the PDN connection,

[0263] A method or procedure for initiating a dedicated bearer activation procedure (e.g. on a secondary eNB via a primary (attach) eNB and RC connection) at a PGW may be performed as described herein (e.g. and shown in FIG. 59). Initially, RRC connections between the UE and the eNBl and the eNB2 may be established or set up. Additionally, the MME may not have other eNBs details that the UE may be connected to and the eNBl and eNB2 may be served by the same SGW.

[0264] Various messages or information may be provided and/or used to perform a PGW initiated dedicated bearer activation procedure such as a NAS: INITIATE SECONDARY CONN RE, QUEST. Such a message may be sent by the MME and may be used to request the UE to initiate a secondary connection from the UE to M ME. in such an embodiment, as there may be a RRC connection available, for example, from the UE to eNB2, a SI logical connection may be established from eNB2 to M E. Such a message may include a direction such as MME UE, a message format, a list of eNBs that may be served by the SGW, and/or information in Table 9.

[0265] The messages may also include a NAS: INITIATE SECONDARY CONN ACCEPT. Such a message may be sent by the UE to the MME after making sure that it may have selected a secondary eNB from the eNB list that may be provided in NAS: INITIATE SECONDARY CONN REQUEST and may establish a RRC connection with it. Such a message may include a direction such as UE > MM E, a message formation, and/or information shown in Table 10,

Table 10: IN ITIATE SECONDARY CONN ACCEPT message content

[0266] The messages may also include a NAS : INITIATE SECONDARY CONN REJECT.

Such a message may be sent when the UE may not have a RRC connection to the eNBs mentioned in the NAS: INITIATE SECONDARY CONN REQUEST. The UE may send the NAS: INITIATE SECONDARY CONN REJECT to the MME via the eNBl . After receiving the NAS: INITIATE SECONDARY CONN REJECT from the MME, the M ME may try to establish the dedicated bearer on the eNBl by sending a SIAP: E-RAB SETUP REQUEST. Such a message may include a direction such as UE ----> MME, a message format, and/or information shown in Table 1 1 .

[0267] To perform a PGW initiated dedicated bearer activation (e.g. with a secondary eNB via a primary (attach) eNB and a RRC connection established with the UE, the PGW may send across a S5: Create Bearer Request to the SGW by including the LBI, EPS bearer id:0, and PGW S5-U PGW TEID. By sending the EPS bearer id:0, the PGW may expect the MME to assign a proper bearer id.

[0268] The SGW may further send the S 11 : Create Bearer Request to MME by including the LBI ,EPS bearer id:0, and Sl-U SGW TEIDfSGW TEID2). By sending the EPS bearer id:0, the SGW may expect the M ME to assign a proper bearer id. [0269] As there may no other eNB associated with the UE that may be served by the SOW, the MME may send across the SI AP: DOWNLINK. NAS TRANSPORT(NAS: INITIATE SEC NDARY CONN REQUEST) to the eNBl . The MME may include the list of eNBs that may be served by the SOW in the NAS: INITIATE SECONDARY CONN REQUEST message. In an embodiment, there may be a limit on the number of eNBs that may be included in the NAS: INITIATE SECONDARY CONN REQUEST message.

[0270] The eNBl may forward the NAS: I ΓΠΑΤΕ SECONDARY CONN REQUEST to the UE. The LIE may then select an eNB (e.g. the eNB2) from the list included in NAS:

INITIATE SECONDARY CONN REQUEST, to which it may have a RRC connection available or already established. The UE may send across the NAS: INITIATE SECONDARY CONN ACCEPT to the selected eNB (e.g. the eNB2). The UE may include a S-TMSI along with the NAS message as the UE may be sending the NAS message for the first time on the eNB2. In an embodiment (e.g. when the UE may not find the eNB from the list included in the NAS:

INITIATE SECONDARY CONN REQUEST to which it may have or may establish an RRC connection), the UE may send across the NAS: INITIATE SECONDARY CONN REJECT to the eNBl in a S1AP: UPLINK NAS TRANSPORT message. If the MME may receive a NAS: INITIATE SECONDARY CONN REJECT, the MME may try to setup the dedicated bearer on the eNBl by sending a S1AP:E-RAB SETUP REQUEST, if MME may see that the eNBl may be free. Otherwise, the MME may fail the dedicated bearer procedure by sending a result code with "No Resource Available" in the S I 1 : Create bearer Response.

[0271] As there may be no SI logical connection from the eNB2 to the MME, the eNB2 may create a SI logical connection and may send across a SLAP: INITIAL UE MESSAGE/NAS: INITIATE SECONDARY CONN ACCEPT) to the MME. The eNB2 may include the eNB2 UE SLAP ID I created for the newly created SI logical connection,

[0272] The MME may identify an unused bearer (id:6) and may send across a S1AP: E-RAB SETUP REQUEST (NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST) to the eNB2. The 8! AP: INITIAL CONTEXT SETUP REQUEST may have a bearer id:6, Qos, and SGW Sl-U TEID(SGW_TEID2) for such a bearer. The dedicated bearer may also have the same IP address of the default bearer of the PDN connection. The MME may set 'MME LIE S1AP ID' to MME UE S1AP ID2 and 'eNB UE S1AP ID' to 'eNB2 UE S1AP ID1 ' as there may be no SI-MME logical connection from the eNB2-MME (e.g. as shown in FIG. 46 that may illustrate logical SI -connections for UE across multiple eNBs). The eNB2 may also set up a EPS bearer id:6, and may forward a MAS: ACTIVATE DEDICATED EPS BEARER

CONTEXT REQUEST, (bearer id: 6)to the UE.

[0273] After establishing the bearer on the eNBl, it (e.g. the eNB2) may send a SI AP:

INITIAL CONTEXT SETUP RESPONSE, (bearer id: 6) to the MME by including its S I A IP and TEID(eNB2 TEIDl). The SLAP: INITIAL CONTEXT SETUP RESPONSE may have the list of bearers that may have been successfully setup on eNB2.

[0274] The UE may then establish the bearer and may send across NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT, (bearer id: 6) to the eNB2. The eNB2 may then send a SIAP: UPLINK NAS TRANSPORT (NAS: ACTIVATE DEDICATED EPS BE ARER CONTEXT ACCEPT), (bearer id: 6) message to the MME.

[0275] The MME may send across a SI 1 : Create Bearer Response(bearer id: 6) to the SGW. In an embodiment, the MME may include eNB2's Sl-U IP and eNB2 TEIDl in the message as well as the LBIidefauit bearer). The SGW may send across S5: Create Bearer Response(bearer id:6) to the PGW, which may include the LBI(default bearer).

[0276] After performing a PGW initiated dedicated bearer activation as described above, user plan traffic may be routed. For example, the eNB2 may send uplink user plane data (UL) or UL user data to the SGW⁷ on Sl-U using SGW's IP address and SGW TEID2. Additionally, the SGW may send downlink user plane data(DL) or DL user data to the eNB2 on Sl-U using eNBl 's IP address and eNB2_ TEIDl .

[0277] In embodiments, a PGW initiated dedicated bearer activation, for example, on a secondary eNB via a primary (attach) eNB with no RRC connection established with the UE may be provided, performed, and/ or used. In such an embodiment, default and dedicated bearers of a PDN connection may have the same IP address and different bearer ids. Such bearers may have the same IP ad dress even if they may be spread across different (H)eNBs.

[0278] In example embodiments, the PGW initiated dedicated bearer activation, for example, on the secondary eNB via the primary (attach) eNB with no RRC connection may use an attach and/or registration procedure as described herein, a dedicated bearer activation, modification, and/or deactivation on multiple interfaces, capability to have default and dedicated bearers of a PDN across (H )eNBs load balancing including distribution of dedicated bearers across (H)eNBs, service request, and the like. [0279] The PGW may initiate a dedicated bearer activation procedure to establish a dedicated bearer procedure with the UE to push a QoS profile. The PGW may include the LBI (default bearer) in the S5:Create Bearer Request to inform the network (e.g. the MME or SOW) that the new dedicated bearer may be associated with the LBI of the PDN connection.

[0280] A method or procedure for initiating a dedicated bearer activation procedure (e.g. on a secondary eNB via a primary (attach) eNB and no RRC connection) at a PGW may be performed as described herein (e.g. and shown in FIG, 60). Initially, a RRC connection between the UE and the eNBl may be established or set up. Additionally, the MME may not have other eNBs details that the UE may be connected to and the eNB l and eNB2 may be served by the same SGW.

[0281] Various messages or information may be provided and/or used to perform a PGW initiated dedicated bearer activation procedure such as a NAS: INITIATE SECONDARY CONN REQUEST, Such a message may be sent by the MME and may be used to request the LIE to initiate a secondary connection from the UE to MME, In such an embodiment, as there may not be a RRC connection available, for example, from the UE to eNB2, a SI logical connection may be established from eNB2 to the M E. Such a message may include a direction such as MME -» UE, a message format, a list of eNBs that may be served by the SGW, and/or information in Table 12.

[0282] Additionally, the messages may include a NAS : INITIATE SECONDARY CONN ACCEPT. Such a message may sent by the UE to the MME, after making sure that it may have selected a secondary eNB from the eNB list that may be provided in the NAS: INITIATE SECONDARY CONN REQUEST and may have established a RRC connection with it. Such a message may include a direction such as UE→ MME, a message format, and/or information in Table 13. Table 13: INITIATE SECONDARY CONN ACCEPT message content

[0283] A NAS : INITIATE SECONDARY CONN REJECT may also be included in the messages. Such a message may be sent when the UE may not have a RRC connection to the eNBs mentioned in NAS: INITIATE SECONDARY CONN REQUEST. The UE may send NAS: INITIATE SECONDARY CONN REJECT to the MME via the eNBl . After receiving the NAS: I ITIATE SECONDARY CONN REJECT from the M ME, the MME may try to establish the dedicated bearer on the eNBl by sending a SIAP: E-RAB SETUP REQUEST. Such a message may include a direction such as UE ----> MME, a message format, and/or information in Table 14.

Table 14: INITIATE SECONDARY CONN REJECT message content

[0284] To perform a PGW initiated dedicated bearer activation (e.g. with a secondary eNB via a primary (attach) e B and no RRC connection established with the UE), in addition to an attach and distributing default and/or dedicated bearers of a PDN across the (H)eNBs, the PGW may send across a S5: Create Bearer Request to the SGW including the LBI , EPS bearer id:0 and PGW S5-U PGW TEID. By sendmg EPS bearer id:0, the PGW may expect the MME to assign a proper bearer id.

[0285] The SGW may send a SI 1 : Create Bearer Request to MME, by including the LBI ,EPS bearer id:0 and Sl-U SGW TEID(SGW__TEID2). By sending EPS bearer id:0, the SGW may also expect the MME to assign a proper bearer id.

[0286] As there may be no other eNB associated with UE that may be served by the SGW, the MME may send across a SI AP: DOWN LINK NAS TRANSPORT(NAS: INITIATE SECONDARY CONN REQUEST) to the eNB l . The MME may include the list of eNBs that may be served by the SGW in the NAS: INITIATE SECONDARY CONN REQUEST message. In an embodiment, there may be a limit on the number of eN Bs that may be included in the NAS: INITIATE SECONDARY CONN REQUEST message,

[0287] The eNBl may forward a NAS: INITIATE SECONDARY CONN REQUEST to the UE. The UE may select a eNB (e.g. the eNB2) from the list included in NAS: INITIATE SECONDARY CONN REQUEST^', to which it may establish a RRC connection. The UE may then establish a RRC connection to the eNB2. The UE may send across a NAS: INITIATE SECONDARY CONN ACCEPT to the selected eNB (e.g. the eNB2). According to an embodiment, the UE may include S-TMSI along with the NAS message, as UE may be sending the N AS message for the first time on the eNB2. If the UE may not find an eNB from the list included in the NAS: INITIATE SECONDARY CONN REQUEST, to which it may establish RRC connection, the UE may send across a NAS: INITIATE SECONDARY CONN REJECT to the eNBl in a S I AP: UPLI K NAS TRANSPORT message. If MME may receive a NAS: INITIATE SECONDARY CONN REJECT, the MME may try to setup the dedicated bearer on the eNBl by sending S 1AP:E-RAB SETUP REQUEST, if MME sees that the eNBl may be free, otherwise the MME may fail the dedicated bearer procedure by sending result code with "No Resource Available" in a S I 1 : Create bearer Response,

[0288] As there may not be a S 1 logical connection from the eNB2 to MME, the eNB2 may create a S I logical connection and may send across a S 1AP: INITIAL UE MESSAGE(NAS: INITIATE SECONDARY CONN ACCEPT) to the MME. The eNB2 may include eNB2 UE S 1AP ID1 created for the newly created S I logical connection (e.g. in such a message).

[0289] The MME may identify unused bearer (id:6) and may send across a S 1AP: IN ITIAL CONTEXT SETUP REQUEST (NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST)) to the eNB2. The S 1AP: INITIAL CONTEXT SETUP REQUEST may have bearer id:6, Qos, and SGW S l-U TEID(SGW_TEID2) for such a bearer. The dedicated bearer may have the same IP address of the default bearer of this PDN connection. The MME may set 'MME UE S IAP ID' to MME UE S IAP ID2, and 'eNB UE S I AP ID' to 'eNB2 UE SLAP ID! ' as there may not be a S l-MME logical connection from eNB2 to MME (e.g. as shown in FIG. 46 that may illustrate logical SI -connections for UE across multiple eNBs), [0290] The eNB2 may set up the EPS bearer id:6, and may forward a NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST, (bearer id: 6) to the UE. After establishing the bearer on the eNBl, it (e.g. the eNBl) may send a SIAP: INITIAL CONTEXT SETUP RESPONSE, (bearer id: 6) to the MME by including its Sl -U IP and TEID(eNB2_TEIDl ). The SI AP: INITIAL CONTEXT SETUP RESPONSE may have the list of bearers that may have been successfully setup on the eNB2.

[0291] The UE may then establish the bearer and may send across a NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT, (bearer id: 6) to the eNB2. The eNB2 may send a SIAP: UPLINK NAS TRANSPORT (NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT), (bearer id: 6)message to the MME (e.g. in response thereto).

[0292] The MME may send across S I 1 : Create Bearer Response(bearer id:6) to the SGW that may include teNB2's Sl -U IP and eNB2_TEIDl in and/or the LBI (default bearer) in the message. The SGW may then send across a S5: Create Bearer Response(bearer id:6) to the PGW and the SGW may include the LBI (default bearer) in the message.

[0293] User plane traffic may be routed (e.g. after performing the PGW initiated dedicated bearer activation described above and shown in FIG. 60). For example, the eNB2 may send uplink user plane data (UL) or UL user data to the SGW on Sl-U using SGW's IP address and SGW TEID2. Additionally, the SGW may send downlink user plane data (DL) or DL user data to the eNB2 on S l-U using eNBl 's IP address and eNB2_TEIDl .

[0294] Additionally, in em.bodim.en.ts, a UE initiated dedicated bearer modification (e.g. as shown in FIG. 61), a PGW initiated dedicated bearer modification (e.g. as shown in FIG. 62), a UE dedicated bearer deactivation (e.g. as shown in FIG. 63), a PGW initiated dedicated bearer deactivation (e.g. as shown in FIG. 64), and the like may also be provided, performed, and/or used.

[0295] Such a UE initiated dedicated bearer modification (e.g. as shown in FIG. 61), a PGW initiated dedicated bearer modification (e.g. as shown in FIG. 62), a UE dedicated bearer deactivation (e.g. as shown in FIG. 63), a PGW initiated dedicated bearer deactivation (e.g. as shown in FIG. 64), and the like may include or perform an attach and/or registration procedure, a dedicated bearer activation, modification, and/or deactivation on multiple interface, a capability to ha ve default and/or dedicated bearers of a PDN across (H)eNBs load bal ancing including distribution of dedicated bearers across (H)eNBs as described herein. [0296] According to an example embodiment, a failover and/or re-establishing bearers may be provided, performed, and/or used. For example, the MME may move bearers from one (H)eNB to another (H)eNB when the MME may realize that an (H)eNB may be down. As such, a failover may occur and bearers may be re-established on available interfaces during

unavailability of an interface as described herein.

[0297] A method or procedure for providing a failover and/or re-establishing bearers may be may be performed as described herein (e.g. and shown in FIG. 65). Initially, RRC connections between the LIE and the eNBl may be established or set up as well as the eNB2. Additionally, default and/or dedicated bearers may be setup on both the eNBs (e.g. eNBl and eNB2) and the eNBs (e.g. the eNBl and eNB2) may be served by the same SGW. In an embodiment, the MME may be triggered to reestablish the bearers by any suitable message, indication, procedure, method, and the like .

[0298] Various messages or information may be provided and/or used to perform a failover and/or a bearer re-establishment such as a SI 1 : HOLD DOWNLINK DATA. Such a message may be sent by the MME to the SGW⁷ to hold downlink data of the bearers at the SGW. The list of bearers may be pro vided in or along with the message. In an embodiment, such a message may include a direction such as MME -> SG W as well as information in Table 15 and/or bearer context information in Table 16. A bearer context may be provided therefor in Table 16.

Table 15: Information Elements in SI I : HOLD DOWNLINK DATA

Table 16: Bearer Context to be held within Hold Downlink Data

[0299] To perform a fai lover and/or re-establishment (e.g. in addition to other procedures and/or methods such as an attach), the MME may determine, detect, and/or realize that the eNBl may be down. The MME may then send across a S 11 :Hold Downlink Data with the list of the bearers that may have been established on the eNB 1.

[0300] The MME may identify a suitable eNB (e.g. the eNB2) and may send across the SI AP: IN ITIAL CONTEXT SETUP REQUEST (NAS: ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST ,NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT

REQUEST) to the eNB2 by including the list of bearers that may have been established on the eNB l .

[0301] The eNB2 may set up the EPS bearers and may forward, for example, the

ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST, NAS: ACTIVATE

DEDICATED EPS BEARER CONTEXT REQUEST to the UE.

[0302] After establishing the bearers on the eNB2, it may send a SI AP: INITIAL

CONTEXT SETUP RESPONSE to the MME by including its Sl-U IP and TEIDs

(eNB2_TEID<x> where x may vary based on the number of bearers that it may setup). The SIAP: INITIAL CONTEXT SETUP RESPONSE may have the list of bearers that may have been successfully setup on the eNB2.

[0303] The UE may establish the bearers and may send across, for example, NAS:

ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT) to the eNB2. The eNB2 may send a SIAP: UPLINK NAS TRANSPORT (NAS: ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT) message to the MME.

[0304] The UE may then establish the bearers and may send across NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT to the eNB2. The eNB2 may send a SLAP: UPLINK NAS TRANSPORT (NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT) message to the MME. [0305] The MME may then send across a SI 1 : Modify Bearer Request to the SOW that may include eNB2's Sl-U IP and eNB2 TEID<x> where x may vary based on the number of bearers that it may set up in the message.

[0306] The SOW may send across a S 11 : Modify Bearer Response to the MME. The SOW may enable or allow the downlink data on the newly created tunnels on the e B2 for the same bearers.

[0307] After performing a failover or re-establishment as described above, user plan data may be routed. For example, the eNB2 may send uplink user plane data (UL) or UL user data to the SGW on Sl-U using SGW's IP address and SGW TEID<x>. In an example embodiment, additionally TEIDs may also be used if more than one bearer may be moved to the eNB2.

Additionally, the SGW may send downlink user plane data (DL) or DL user data to the eNB2 on Sl-U using eNB2's IP address and eNB2_TEID<x>. Additional TEIDs may be used if more than one bearer may be moved to the eNB2.

[0308] in additional embodiments, PDN connection procedures including a UE initiated PDN connection (e.g. as shown in FIG. 66), a UE initiated PDN disconnect (e.g. as shown in FIG. 67), PGW initiated PDN disconnect (e.g. as shown in FIG. 68), and the like may be provided, performed, and/or used. Such PDN connection procedures may perform and/or use a PDN connectivity request on multiple interfaces as well as a PDN disconnect procedure on multiple interface that may be described herein.

[0309] Additionally, bearer mobility and/or IP flow mobility (IFOM) may be provided and/or used (e.g. with multiple RRC connections). FIG. 69 illustrates a simultaneous connection to multiple eNBs (e.g. the eNB 1 and eNB2), along with 1 EPS-Bearer via the eNBl and 2 EPS- Bearers^. g. EPS-Bearer s2 and 3) via the eNB2. The EPS-Bearers 1 and 2 may carry an I P flow each, whereas EPS-Bearer 3 may cany more than one IP flow as shown therein. In example embodiments, in bearer mobility, a bearer may be moved from one connection or eNB to another connection or eNB such that IP flows associated with that bear being moved may also be moved (e.g. as shown in FIG. 70). IP flow mobility may enable a an IP flow (a single IP flow or a portion thereo) to be moved from an EPS Bearer on an eNB to another EPS Bearer on another eNB to, for example, fine tune bandwidth control (e.g. as shown in FIG. 71).

[0310] In an embodiment, an eNB initiated bearer mobility may be provided and/or used. In such an eNB initiated bearer mobility, an eNB (e.g. the eNBl) may determine or discover that there may be an overload condition and it may initiate the bearer mobility method or procedure disclosed herein to move such bearers or move mforrnatkm from such bearers to another connection such as another RRC connection in the multiple RRC connections or another bearer. As such, the eNB (e.g. the eNBl) may inform the MME to move one or more of its bearers to another eNB (e.g. the eNB2). The M ME may then establish the bearers on the eNB2 and may send across a SI 1 :Modify Bearer Request procedure to the SGW to update the new Sl-U TEID information. In such an embodiment, there may not a change to SGW-PGW interface. Once completed, the MME may then release the bearers on the eNBl and the eNBl may inform the UE to release the bearers.

[0311] A method or procedure for initiating bearer mobility at an eNB may be may be performed as described herein (e.g. as shown in FIG. 72). Initially, a RRC connections between the UE and the eNBl and eNB may be established or set up. Additionally, default and/or dedicated bearers may be set up on both the eNBs (e.g. the eNB land eNB2) and the eNBs (e.g. the eNBl and eNB2) may be served by the same SGW,

[0312] In example embodiments, various messages may be provided and/or used for initiating bearer mobility at an e B such as a S1 AP: BEARER MOVE REQUEST. Such a message may be sent by the eNB to the MME to move at least one of the bearers. In an embodiment, the MME may select an idle eNB to move the bearers to and the eNB may include the list of bearers in SI AP: BEARER MOVE REQUEST message. Such a message may include a direction such as eNB -> MME and /or additional information.

Table 17

[0313] The messages may also include the S 11 : HOLD DOWNLINK DATA. Such a message may be sent by the MME to SGW to hold downlink data of the bearers at the SGW, The list of bearers may be provided the message. Such a message may also include a direction such as MME -> SGW and/or information in Table 18. A bearer context may be provided therefor in Table 19.

Table 18: Information Elements in SI 1 : HOLD DOWNLINK DATA

[0314] To perform an eNB initiated bearer mob lity (e.g. in addition to an attach and'Or default and/or dedicated bearers of a PDN being distributed across (H)eNBs as described herein), the eNB! may send across a SI AP: BEARER MOVE REQUEST to the MME, by including the list of bearers that it may wish to move.

[0315] The MME may send across a S! l :Hold Downlink Data with the list of the bearers it may get or receive from the eNB l in a S1AP: BEARER MOVE REQUEST. Additionally, the MME may send across a S1AP: E-RAB RELEASE COMMAND (NAS: DEACTIVATE EPS BEARER CONTEXT REQUEST) to the eNB! with the list of bearers that may have been provided or included in the S1AP: BEARER MOVE REQUEST.

[0316] The eNBl may release the bearer s and may forward a NAS: DEACTIVATE EPS BEARER CONTEXT REQUEST to the UE. After releasing the bearers on the eNBl, it may further send a S1AP: E-RAB RELEASE RESPONSE to the MME. The S1AP; E-RAB

RELEASE RESPONSE may include or have the list of bearers that may have been successfully released on the eNBl .

[0317] The UE may then release the bearers and may send across a NAS: DEACTIVATE EPS BEARER CONTEXT ACCEPT to the eNBl . After receiving such a message, the eNB! may send a SI AP: UPLINK NAS TRANSPORT (NAS: DEACTIVATE EPS BEARER

CONTEXT ACCEPT)), (bearer id: 6) message to the MME. [0318] The MME may then determine or identify a suitable eNB (e.g. the eNB2) to move to and may send across a S I AP: INITIAL CONTEXT SETUP REQUEST (NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST) to the eNB2 by including the list bearers that may have been included in S1AP: BEARER MOVE REQUEST message. In response thereto, the eNB2 may set up the EPS bearers and may forward , for example, a NAS:

ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST to the UE.

[0319] After establishing the bearers on eNB2, it (e.g. the eNB2) may send a SI AP:

INITIAL CONTEXT SETUP RESPONSE to the MME by including its Sl-U IP and

TEIDs(eNB2 TEID<x> where x may vary based on the number of bearers that it may setup. The SLAP: INITIAL CONTEXT SETUP RESPONSE may include or have the list of bearers that may have been successfully setup on the eNB2.

[0320] The UE may then establish the bearers and may send across a NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT to the eNB2. After receiving such a message, the eNB2 may send a SLAP: UPLINK NAS TRANSPORT (NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT) message to the MME.

[0321] In an embodiment, the MME may send across a SI 1 : Modify Bearer Request to the SGW that may include eNB2's Sl-U IP and eNB2_TEID<x> where x may vary based on the number of bearers that it would set up) in the message. The SGW may then send across a S I 1 : Modify Bearer Response to the MME and the SGW may enable or allow the downlink data on the newly created tunnels on the eNB2 for the same bearers.

[0322] After performing an eNB initiated bearer mobility, user plan data may be routed. For example, the eNB2 may send uplink user plane data (UL) or UL user data to the SGW on Sl-U using SGW's ΪΡ address and SGW_TEID<x>. As described above, more than one TEID may be used if more than one bearer may be moved to the eNB2. Additionally, the SGW may send downlink user plane data (DL) or DL user data to the eNB 2 on Sl -U using eNB2's IP address and eNB2_TEID<x>. Similarly, more than one TEID may be used if more than one bearer may be moved to the eNB2.

[0323] A MME (or even PGW) initiated bearer mobility may also be provided and/or used as described herein. In an embodiment, based on criteria such as policy or network conditions, and the like, the MME (or PGW) may initiate a bearer mobility. For example, a PGW may send across a SI I : Update Bearer Request to the MME via the SGW, to modify QoS and other parameters. Such a procedure or operation may trigger the MME to move one or more bearers from an eNB (e.g. the eNBl) to another eNB (e.g. the eNB2). The MME may establish the bearers on eNB2 and may send across the S 1 1 Modify Bearer Request procedure to SGW to update the new Sl-U TEID information. According to an example embodiment, there may not be a change to the SGW-PGW interface. The M ME may then release the bearers on the eNB and the eNBl may inform the UE to release the bearers.

[0324] A method or procedure for initiating bearer mobility at a MME may be performed as described herein (e.g. as shown in FIG. 73). Initially, a RRC connections between the UE and the eNBl and eNB may be established or set up. Additionally, default and/or dedicated bearers may be set up on both the eNBs (e.g. the eNB land eNB2) and the eNBs (e.g. the eNB l and eNB2) may be served by the same SGW.

[0325] In example embodiments, various messages may be provided and/or used for initiating bearer mobility at a MME such as a SIAP: INITIL CONTEXT SETUP REQUEST that may include a modified QoS. For example, a modified QoS from a SI 1 Update Bearer Request may be inserted or included in SIAP: INITIAL CONTEXT SETUP REQUEST. The modified QoS may then be sent across in a SI AP:E-RAB MODIFY REQUEST (e.g. another message that may be used herein). As the bearers may be setup on the eNB2, the MME may take final changes and may send then across in SIAP: INITIAL CONTEXT SETUP REQUEST message.

[0326] Such messages may include a bearer context within an update bearer response (e.g. as shown in Table 20) and may have TEID information. The Sl-U eNodeB F-TEID, Sl-U SGW F- TEID may be IBs that may be used.

Table 20: Bearer Context within Update Bearer Response

[0327] Another message may include a SI 1 : HOLD DOWN LINK DATA. Such a message may be sent by the MME to the SGW to hold downlink data of the bearers at the SGW. The list of bearers may be provided in the message. Such a message may also include a direction such as MME ~> SGW and/or information, for example, in Table 21 as well, as may provide a bearer context, for example, in Table 22.

Table 2.1 : Information Elements in 8.1 1 : HOLD DOWNLINK DATA

[0328] To perform a MM E initiated bearer mobility, an attach may be performed and default and dedicated bearers of a PDN may be distributed across (H)eNBs. The PGW may send across a S I 1 : Update Bearer Request message to the SGW with certain QoS parameters and may include dedicated bearers. The SGW may then send across the S I 1 : Update Bearer Request message to the MME.

[0329] Based on the QoS parameters that may be received from the SGW, the MME may determine or decide to move the bearers from the eNBl to another eNB (e.g. the eNB2). The MME may then send across a S I 1 :Hold Downlink Data message to the SG W and a S 1AP: E- RAB RELEASE COMMAND (NAS: DEACTIVATE EPS BEARER CONTEXT REQUEST) to the eNBl with the list of bearers that may be moved from the eNBl ,

[0330] In response thereto, the eNBl may release the bearer s and may forward a NAS: DEACTIVATE EPS BEARER CONTEXT REQUEST to the UE. After releasing the bearers on the eNBl , it may send a S 1AP: E-RAB RELEASE RESPONSE to the MME. The S 1AP: E- RAB RELEASE RESPONSE may include or have the list of bearers that may have been, successfully released on the eNBl .

[0331 ] The UE may release the bearers and may send across a NAS: DEACTIVATE EPS BEARER CONTEXT ACCEPT to the eNBl . The eNBl may send a S 1AP: UPLINK NAS TRANSPORT (NAS: DEACTIVATE EPS BEARER CONTEXT ACCEPT)), (bearer id: 6) message to the ME. [0332] The MME may determine or identify a suitable eNB (e.g. the eNB2) and may send across a SI AP: INITIAL CONTEXT SETUP REQUEST (NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST)) to the eNB2 by including the list bearers that may have been released on the eNBl along with modified QoS information.

[0333] The eNB2 may set up the EPS bearers and may forward a MAS: ACTIVATE

DEDICATED EPS BEARER CONTEXT REQUEST to the UE. After establishing the bearers on the eNB2, it may send a SI AP: INITIAL CONTEXT SETUP RESPONSE to the M ME by including its SI-U IP and TEIDs (e.g. eNB2 TEID<x> where x may vary based on the number of bearers that it may setup). The S1AP: INITIAL CONTEXT SETUP RESPONSE may have the list of bearers that may have been successfully setup on the eNB2.

[0334] The UE may then establish the bearers and may send across a NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT to the eNB2. The eNB2 may send a SIAP: UPLINK NAS TRANSPORT (NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT) message to the MME.

[0335] In response thereto, the MME may send across SI I : Update Bearer Response to the SGW. The M ME may include, in the message, eNB2's Sl-U IP and eNB2_TEID<x> where x may vary based on the number of bearers that it may set up. The SG W may enable or allow the downlink data on the created tunnels on the eNB2 for the same bearers. The SGW may then send across a SI 1 : Update Bearer Response to the PGW.

[0336] After providing or performing MME initiated bearer mobility, user plane traffic may be routed. For example, the eNB2 may send uplink user plane data (UL) or UL user data to the SGW on Sl-U using SGW's IP address and SGW TEID<x>. As described above, additional TEIDS may be used if more than one bearer may be moved to the eNB2. Additionally, the SGW may send downlink user plane data (DL) or DL user data t theo eNB2 on Sl-U using eNB2's IP address and eNB2 TE!D<x>. Similarly, additional TEIDs may be used if more than one bearer may be moved to the eNB2.

[0337] In additional embodiments, a UE initiated bearer mobility (e.g. as shown in FIG. 74)may be provided, performed, and/or used as described herein. For example, a LIE may request that the MME move one of its bearers from one eNB (e.g. the eNBl) to another eNB (e.g. the eNB2), The MM E may then establish the bearers on the eNB2, According to an example embodiment, the MME may choose an available eNB and may send across a SI I :Modify Bearer Request procedure to the SOW to update the Sl-U TEID information. Additionally, in an embodiment, there may not be changes to the SGW-PGW interface. The MME may release the bearer on the eNBl and the eNBl may inform the UE to release the bearer.

[0338] A method or procedure for initiating bearer mobility at a UE may be performed as described herein (e.g. as shown in FIG. 74). Initially, RC connections betw^reen the UE and the eNBl and eNB may be established or set up. Additionally, default and/or dedicated bearers may^¬ be set up on both the e Bs (e.g. the eNBl and eNB2) and the eNBs (e.g. the eNBl and eNB2) may be served by the same SGW.

[0339] In example embodiments, various messages may be provided and/or used for initiating bearer mobility at a UE such as a NAS: MOVE EPS BEARER CONTEXT

REQUEST. Such a message may be sent by the UE to request that an active EPS bearer context be moved. According to embodiments, such a message may include a message type such as MOVE EPS BEARER CONTEXT REQUEST, a significance such as dual, a direction such as

UE to network, and/or information shown in Table 23.

Table 23: MOVE EPS BEARER CONTEXT REQUEST message content

[0340] To perform a UE initiated bearer mobility, an attach may be performed and/or default and/or dedicated bearers of a PDN may be distributed across the (H)eNBs. Additionally, the UE may send across a NAS:MOVE EPS BEARER CONTEXT REQUEST to the eNBl to move one of its bearers to another eNB (e.g. the eNB2). The UE may include the EPS bearer id in the NAS message.

[0341] The eNBl may send across a SIAPUIPLINK NAS TRANSPORT(NAS :MOVE EPS BEARER CONTEXT REQUEST) to the ME. in response thereto, in an embodiment, the MME may send across a SI 1 :Hold Downlink Data with the bearer that may have received from the eNBl in the S 1 AP :UPLIN NAS TRANSPORT(NAS:MOVE EPS BEARER CONTEXT REQUEST).

[0342] The MME may send across a SIAP: E-RAB RELEASE COMMAND (NAS:

DEACTIVATE EPS BEARER CONTEXT REQUEST) to the eNBl with the bearer that may have be included in the NAS MOVE EPS BEARER CONTEXT REQUEST,

[0343] The eNBl may then release the bearers and may forward a NAS: DEACTIVATE EPS BEARER CONTEXT REQUEST to the UE. After releasing the bearer on the eNBl , it (e.g. the eNBl) may send a SIAP: E-RAB RELEASE RESPONSE to the MME. The SIAP: E-RAB RELEASE RESPONSE may have the bearer that may have been successfully released on the eNBl .

[0344] The UE may then release the bearer and may send across a NAS: DEACTIVATE EPS BEARER CONTEXT ACCEPT to the eNBl . The eNB l may send a SIAP: UPLINK NAS TRANSPORT (NAS: DEACTIVATE EPS BEARER CONTEXT ACCEPT)), (bearer id: 6) message to the MM E.

[0345] In an embodiment, the MME may determine or identify a suitable eNB (e.g. the eNB2 to move the bearer to) and may send across a SI AP: I ITIAL CONTEXT SETUP REQUEST (NAS: ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST) to the eNB2 by including the bearer that may have been included in the NAS: MOVE EPS BEARER CONTEXT REQUEST message.

[0346] The eNB2 may set up the EPS bearer and may forward the NAS : ACTIVATE

DEDICATED EPS BEARER CONTEXT^' REQUEST to the UE. After establishing the bearer on the eNB2, it (e.g. the eNB2) may send a SIAP: INITIAL CONTEXT SETUP RESPONSE to the MM E by including its Sl -U IP and TEID(eNB2_TEID 1 ). The SI AP: IN ITIA L CONTEXT SETUP RESPONSE may have the bearer that may have been successfully setup on the eNB2.

[0347] The UE may establish the bearer and may send across a NA S: ACTIVATE

DEDICATED EPS BEARER CONTEXT ACCEPT to the eNB2. The eNB2 may then send a SI AP: UPLINK NAS TRANSPORT (NAS: ACTIVATE DEDICATED EPS BEARER

CONTEXT ACCEPT) message to the MME.

[0348] After receiving such a message, the MME may send across a SI I : Modify Bearer Request to the SOW. The MME may include eNB2's Sl -U IP and eNB2_TEIDl in the message. The SGW may then send across a SI 1 : Modify Bearer Response to the MME and the SOW may enable or allow the downlink data on the created tunnel on the eNB2 for the same bearer,

[0349] User plane traffic may be routed (e.g. after a UE initiated bearer mobility). For example, the eNB2 may send uplink user plane data (UL) or UL user data to the SGW on S.1 -U using SGW's ΪΡ address and SGW_TEID<x>. In embodiments, as described above, additional TEIDs, may be used if more than one bearer may be moved to the eNB2, Additionally, the SGW may send downlink user plane data (DL) or DL user data to the e B2 on S l-U using eNB2's IP address and eNB2 TEID<x>. Additional TEIDs may also be used if more than one bearer may be moved to the eNB2.

[0350] As described above, IP flow mobility (IFOM) may be provided, performed, and/or used herein (e.g. when multiple RRC connections may be established and/or maintained). In one embodiment, such IP flow mobility may include a PGW initiated IP flow mobility. In such an embodiment, a PGW may send across a SI 1 : Update Bearer Request to the MME via the SGW to, for example, move an IP flow of a dedicated bearer or RRC connection to another dedicated bearer or RRC connection. Such bearers may be distributed across different eNBs and may belong to the same PDN connection. Additionally, a packet filter ID may be used and may be unique across the TFTs within a PDN connection.

[0351] A method or procedure for initiating IP flow mobility at a PGW may be performed as described herein (e.g. as shown in FIG. 75). Initially, RRC connections between the UE and the eNBl and eNB2 may be established or set up. Additionally, an attach may be performed on the eNBl as described herein, dedicated bearers may be set up on both the eNBs (e.g. the e Bl and eNB2), and the eNBs (e.g. the eNBl and eNB2) may be served by the same SGW. A first IP flow (e.g. IP FLOW!) may be on the e Bl .

[0352] In example embodiments, various messages or functions may be provided and/or used for initiating IP flow mobility at a PGW such as S 1 AP:DOWNLINK NAS

TRANSPORT(NAS MODIFY EPS BEARER CONTEXT REQUEST) that may be constructed by the MME and may be sent across to the eNBl and eNB2.

[0353] To perform a PGW initiated IP flow mobility (e.g. in addition to an attach procedure and default and/or dedicated bearers of a PDN being distributed across (H)eNBs), the PGW may send across a S I 1 : Update Bearer Request message to the SGW by including EPS bearer id:6 for a dedicated bearer that may be on eNBl, and EPS bearer id:7 for a dedicated bearer that may be on eNB2 As the PGW may wish or want (e.g. like) to move the first IP flow (e.g.IP FLOW1) from bearer id:6 (e.g. the eNBl) to bearer id:7 (e.g. the eNB2), the PGW may delete the packet filter of the IP FLOW1 from a TFT that may be associated with bearer id:6 and may add the packet filter of IP FLOW1 to a TFT that may be associated with bearer id:7.

[0354] In an embodiment, the SOW may send across a S 1 1 : Update Bearer Request message to MME. Based on TFT parameters that may be received from the SOW (e.g. in a message such as the SI 1 : Update Bearer Request message or other message), the MME may construct multiple (e.g. two) S I AP:DOWNLIN NAS TRANSPORTfNAS MODIFY EPS BEARER CONTEXT REQUEST)(s). In a first NAS MODIFY EPS BEARER CONTEXT REQUEST, the MME may include EPS bearer id:6, and the modified TFT where TFT may not have a packet filter for IP FLOW1 and may send across such a message to the eNBl . In a second NAS MODIFY EPS BEARER CONTEXT REQUEST, the MME may include EPS bearer id:7, and the modified TFT where TFT may have the packet filter for IP FLOW I and may send across such a message to the eNB2,

[0355] In response thereto, the eNB 1 may send across the NAS : MODIFY EPS BEARER CONTEXT REQUEST to UE and the UE may send across a NAS MODIFY EPS BEARER CONTEXT ACCEPT to eNBl . The eNBl may then send across a SI AP:UPLIN NAS TRANSPORT(N AS MODIFY EPS BEARER CONTEXT ACCEPT) to the MME.

[0356] The eNB2 may also send across a NAS MODIFY EPS BEARER CONTEXT REQUEST to the UE and the UE may send across a NAS: MODIFY EPS BEARER CONTEXT ACCEPT to the eNB2. In response thereto, the eNB2 may send across a S1AP:UPLINK NAS TRANSPORT (NAS MODIFY EPS BEARER CONTEXT ACCEPT) to the MME. The MME may send across a SI 1 : Update Bearer Response to the SGW and the SGW may send across S 11 : Update Bearer Response to the PGW.

[0357] User plane traffic may then be routed (e.g. after a PGW initiated IP flow mobility). For example, the eNB2 may send uplink user plane data (UL) or UL user data to the SGW on Sl-U using SGW's IP address and SGW TEID<x> and the SGW may send downlink user plane data (DL) or DL user data to the eNB2 on Sl-U using eNB2's IP address and eNB2_ TEID<x>.

[0358] In additional embodiments, a UE initiated IP flow mobility may be provided, performed, and/or used. In such an embodiment, a UE may request that the M E move one of its IP flows from a dedicated bearer or RRC connection (e.g. on eNBl or established with the eNBl) to another dedicated bearer or RRC connection (e.g. on eNB2 or established with the eNB2). Additionally, a packet filter D may be used and may unique across TFTs within a PDN connection.

[0359] For example, a method or procedure for initiating P flow mobility at a UE may be performed as described herein (e.g. as shown in FIG. 76). Initially, RRC connections between the UE and the eNBl and eNB2 may be established or set up. Additionally, an attach may be performed on the eNBl as described herein, dedicated bearers may be set up on both the eNBs (e.g. the eNBl and eNB2), default and/or dedicated bearers on the eNBs (e.g. the eNBl and the eNB2) may belong to the same PDN connection, and the eNBs (e.g. the eNBl and eNB2) may be served by the same SOW. A first IP flow (e.g. IP FLOW!) may be on the eNBl .

[0360] In example embodiments, various messages or functions may be provided and/or used for initiating IP flow mobility at a UE such as NAS: MOVE IP FLOW REQUEST. Such a message may be sent by the UE to the network to move an IP flow from one bearer to another bearer. Such a message may include a message type such as MOVE IP FLOW REQUEST, a significance such as dual, a direction such as UE to network, and/or information shown in Table

Table 24: MOVE IP FLOW REQUEST message content

[0361 ] The messages may further include a SI 1 : IP FLOW MOVE COMMAND. In embodiment, an IP FLOW MOVE COMMAND message may be sent from a MME to a and may be forwarded to a PGW as part of the UE requested IP flow mobi lity procedure a message may mclude the information in Table 25.

Table 25: Inforaiation Elements in a IP Flow Move Command

[0362] To perform a U initiated IP flow mobility (e.g. in addition to an attach procedure and default and/or dedicated bearers of a PDN being distributed across (H)e Bs), the UE may send across a NAS MOVE IP FLOW REQUEST to the eNBl to move one of its IP flows from a dedicated bearer;6 (e.g. on the eNBl ) to another dedicated bearer:? (e.g. on the eNB2). The UE may include the source EPS bearer id:6, source TAD (trafficflow aggregate description), destination EPS bearer id:7, destination TAD, and the like in the NAS message.

[0363] The eNBl may send across a S1AP:UPLIN NAS TRANSPORT(N AS : MOVE IP FLOW REQUEST) to the MME. The MME may then send across a SI 1 :IP Flow Move

Command to the SGW with the desired parameters that may be received from the UE in the NAS:MOVE IP FLOW REQUEST,

[0364] The SGW may send across a S5:IP Flow Move Command to the PGW. In an embodiment, the PGW may construct a S5 Update Bearer Request and may send across such a message to the SGW⁷, The PGW may remove a packet filter(e.g. of IP FLOW1) from a source bearer TFT associated with a source EPS bearer and may add a packet filter to a destination bearer TFT associated with a destination EPS bearer.

[0365] After receiving such a message, the SGW may send across SI 1 Update Bearer Request to the MME, As there may no QoS changes, according to an embodiment, the MME may send across a S 1 AP:DOWNLINK NAS TRANSPORT(NAS:M()DIFY EPS BEARER CONTEXT REQUEST) to the eNBl (e.g. for the source EPS bearer:6).

[0366] The eNBl may then send across a NAS MODIFY EPS BEARER CONTEXT REQUEST to the UE and the UE may send across a NAS MODIFY EPS BEARER CO NTEXT ACCEPT to the eNBl .

[0367] In response thereto, the eNBl may send across a SI AP:UPLIN NAS

TRANSPORT(N AS MODIFY EPS BE ARER CONTEXT ACCEPT) to the MME. As there may^¬ be no QoS changes, the MME may send across a SI AP:DOWNLINK NAS

TRANSPORT (NAS MODIFY EPS BEARER CONTEXT REQUEST) to the eNB2 (e.g. for destination EPS bearer:7).

[0368] The eNB2 may send across a NAS MODIFY EPS BEARER CONTEXT REQUEST to the UE. The UE may then send across a NAS MODIFY EPS BEARER CONTEXT ACCEPT to the eNB2 such that the eNB2 may send across a S 1AP UPLINK NAS

TRANSPORT(N AS MODIFY EPS BEARER CONTEXT ACCEPT) to the MME. The MME may then send across a S 1 1 Update Bearer Response to the SGW and the SGW may send across a S5 Update Bearer Response to the PGW,

[0369] User plane traffic may then be routed (e.g. after or during a UE initiated I P flow mobility. For example, the eNB2 may send uplink user plane (UL) or UL user data to the SGW on Sl-U using SGW's IP address and SGW_TEID<x>. IP FLOW 1 may then be transferred via the eNB2, Additionally, the SGW may send downlink user plane data (DL) or DL user data to the eNB2 on Sl-U using eNB2's IP address and eNB2_TEID<x>. The IP FLOW 1 may also be transferred via the e B2.

[0370] According to an embodiment, a BW C (e.g. a Bandwidth Management Controller) may be provided and/or used, for example, with multiple RRC connections. FIGs. 77-78 depict example architectures that may include a BWMC¹ controller. As shown in FIGs. 77-78, the BWMC may be between the eNBs (e.g. the eNB 1 and eNB2) and the SGW and may be in communication therewith. The BWMC may control a mapping of (H)eNB Tunnel Endpoint IDs (TEIDs) and SGW TEIDs for user plane traffic, may provide an interface with multiple

(H)eNBs ,may hide (H)eNB details and may act as if it may be sending control/user plane data to MME/SG, may provide control plane functionality between (H)eNBs and the MME (Sl-MME), may provide "indirect" user plane between (H)eNBs and the SGW (Sl-U), may provide a "direct" user plane between (H)eNBs and the SGW (Sl -U), and the like. The BWMC may also reduce or not unduly impact the loading on the existing network nodes such as the MME and SGW by using "flow mobility" across multiple eNBs.

[0371] FIG. 79-82 illustrate example PDN connection maps that may be used with a BWMC. For example, FIG. 79 may illustrate eNB-SGW broken tunnels at a BWMC where default, dedicated bearers of a PDN connection may map to a PDN. As shown in FIG. 79, default and dedicated bearers may belong to the same PDN connection 1 and as such they may share the same IP address. The PDN connection 1 may also map to PD l . According to an embodiment, such bearers may have different bearer ids.

[0372] FIG. 80 illustrates eNB-SGW broken tunnels at a BWMC where two default bearers of different PDN connections may map to the same PDN. In FIG. 80, two default bearers of different PDN connections (e.g. PDN connection 1 & PDN connec†ion2) may be connected to the same PDNl . Such bearers may have different IP addresses and may have bearers with different bearer ids.

[0373] FIG. 81 illustrates eNB-SGW broken tunnels at a BWMC where default and dedicated bearers of a PDN connection may map to a PDN using the same eNB. As shown in FIG. 81 , default and dedicated bearers of a PDN connection may be connected to the same PD l . Such bearers may have same IP address, but may have different bearer ids and may be established on the same eNB (e.g. the eN Bl).

[0374] FIG. 82 illustrate eNB-SGW broken tunnels at a BWMC where two default bearers of different PDN connections may map to different PDNs. in FIG. 82, default bearers may belong to different PDN connections and may have different I P addresses. The PDN connection] & PDN connection 2 may map to PDNl and PDN2 respectively. Additionally, such bearers may- have different bearer ids.

[0375] FIG. 83 is a diagram illustrating connections such as logical connections and RRC connections across multiple eNBs and a BWMC. As shown in FIG. 83, there may be three physical SI connections such as eNBl -BWMC, eNB2-BWMC, and BWMC-MME.

Additionally, there may be four logical S I -connections such as eNBl -BWMC logical 81 - connection 1 that may be identified by eNBl UE S IAP ID l , BWMC UE S IAP IDl , BWMC- MME logical S I -connection 1 may be identified by BWMC UE S IAP ID2, MME UE SIAP ID 1 , e B2-B WMC logical S 1 -connection 1 that may be identified by e B2 UE S 1 AP ID 1 , BWMC UE S IAP ID3, BWMC-MME logical S I -connection 2 that may be identified by BWMC UE S IAP ID4, MME UE S I AP ID2,

[0376] In embodiments described herein, the B WMC may be placed between (H)eNB and MME. There may be a BWMC S I -MME link that may exist between a (H)eNB and BWMC. Multiple (H)eNBs may connect to a single BWMC. Another S 1-MME link may be provided between the BWMC and MME. For the MME, the BWMC may act as an eNB, hiding the details of (H)e Bs. In an embodiment, a He B premises may include a He B and a CGW (e.g. a converged gateway). The CG ^' may have the intelligence to segregate data flows based on policies (e.g. segregation). According to an example embodiment, the procedures described above (e.g. with respect to BWM or BWM-MME) may be applied to the BWMC. For example, an attach procedure (e.g. as described herein) or a UE initiated dedicated bearer activation (e.g. as described herein) may be performed . Other procedures and/or methods (or call flows) may also be provided and/or used.

[0377] Additionally, in embodiments, the B W MC that may be used may be a stand-alone component, may be co-located with MME, and/or may be co-located with eNB/^'H(e)NB.

When the BWMC¹ may be co-located with the M ME, in an embodiment, the BWMC may support a user plane as it may be a burden on the MME to support both the user plane and control plane thereby degrading the performance of the MME.

[0378] In example embodiments, interfaces (e.g. as described above) may be provided and/or used herein. For example, a LTE-Uu interface may be provided and/or used. The LTE-Uu may^¬ be an interface between the UE and an e B that may support embodiments disclosed herein, [0379] For example, the UE may be modified to connect to multiple (H)eNBs at the same time. As such, the UE may have an option configured by the user to have BWM for such multiple connections that may be defined as a "bwmmeEnableFlag." According to an example embodiment, if the flag value may be FALSE, the UE may not have capability to connect to multiple (H)eNBs at the same time. However, if the flag value may be TRUE, the UE may be able to connect to multiple (H)eNBs at the same time. Additionally, the UE may establish a RRC connection dynamically when a new candidate (H)eNB may be identified by the UE. The LTE-Uu may support (e.g. may include or cany) one or more of the following messages: the RRCConnectionSetup, the RRCConnectionUpdate, and the like.

[0380] A S 1 -MME and/or a NAS interface may also be provided and/or used. The S 1 -MME may be the interface between a (H)eNB and MME. in embodiments, the SI -MME interface may be an extension of the SI interface to support the embodiments disclosed herein or a new interface. The SI-MME interface may support (e.g. may include or carry) the S1AP: INITIAL CONTEXT SETUP S I CONNECT REQUEST, the SI AP: BEARER MOVE REQUEST, and the like.

[0381] The NAS may be the interface or protocol (e.g. messages) that may be used between the UE and MME. The NAS may support (e.g. may include or carry) one or more of the following messages described herein: NAS: UPDATE ENBLIST REQUEST, NAS: ATTACH REQUEST, NAS: INITIATE SECONDARY CONN REQUEST, NAS: INITIATE SECONDARY CONN ACCEPT, NAS: INITIATE SECONDARY CONN REJECT, NAS: MOVE EPS BEARER CONTEXT REQUEST, NAS: MOVE IP FLOW REQUEST, and the like.

[0382] In an embodiment, a SI 1 interface may be provided and/or used. The SI 1 may be the interface between the MME and SOW. The Sl l interface may support (e.g. may include or carry) the SI LRelease Access Bearer Request, Sl l : Hold Downlink Data, SI LUpdate Bearer Request, Sl l : IP Flow Move Command, and the like. [0383] Additionally, a S5 and a S6a interface may be provided and/or used. The S5 may be the interface between the SGW and PGW that may support (e.g. may include or carry) the

S5:Release Access Bearer Request message, a S5: IP Flow Move Command, and the like. The S6a may be the interface between the MME and HSS that may support (e.g. may include or cam') one or more of the following messages: S6a:Update Location Answer (e.g. during an attach procedure the HSS may send across the BWM-Flag in a subscription), S6a:Insert Subscriber Data Request (e.g. an ISD request may have the BWM-Flag in a subscription), and the like.

[0384] In example embodiments, multiple RRC connections may have an impact on a UE and network nodes. For example, the UE may maintain a state machine for each RRC connection that may be established between the UE and an eNB. The UE may also share spectrum with the eNBs. In an embodiment, the UE may maintain a RRC connection ID at an application level above the RRC layer to logically group a set of radio bearers under a RRC connection ID. The RRC connection ID may be used locally at the UE and may not be sent across to e B.

[0385] The UE may also have an option configured by the user to have BWM including a '^"BWM-Flag," as described above. If the flag value may be FALSE, the UE may not have capability to connect to multiple (H)eNBs at the same time. Additionally, if the flag value may be TR UE, the UE may connect to multiple (H)eNBs at the same time. The UE may further establish a RRC connection when a new (H)eNB may be identified by the UE.

[0386] The (H)eNB may also be impacted as described above as well as the MME. For example, with regard to the MME, the purpose of the UE Context Release Request procedure may be to enable the eNB to request the MME to release the UE-associated logical Sl- connection due to a E-UTRAN generated reason (e.g. "TX2RELOCOverall Expiry"). Such a procedure may use UE-associated signaling. The UE CONTEXT RELEASE REQUEST message may indicate the appropriate cause value, for example, "User Inactivity", "Radio Connection With UE Lost," and the like for the requested UE-associated logical S I -connection release. When a MME may receive a SI AP:UE CONTEXT RELEASE REQUEST from an eNB, the MME may release the logical SI -connection associated with the eNB and may update corresponding connection state variable to IDLE, The MME may also maintain a global state variable for each UE and may have states such as CONN ECTED, IDLE, and the like. The global state variable at the MME may become IDLE, for example, when the logical S 1- connections/RRC connections may be released.

[0387] Periodic tracking area updating may be used to periodically notify the availability of the UE to the network. The procedure is controlled in the UE by the periodic tracking area update timer (timer T3412). The value of timer T3412 may be sent by the network to the UE in the ATTACH ACCEPT message and may be sent in the TRACKING AREA UPDATE

ACCEPT message. The UE may apply this value in all tracking areas of the list of tracking areas that may be assigned to the UE, until a new value may be received.

[0388] The timer T3412 may be reset and started with its initial value, for example, when the UE may go from EMM-CONNECTED to EMM-IDLE mode. The timer T3412 may be stopped when the UE may enter a EMM-CONNECTED mode or EM M -DE REG I S TERED state. When timer T3412 may expire, the periodic tracking area updating procedure may be started and the timer may be set to its initial value for the next start. With multiple RRC connections, the UE may start the T3412 timer when the UE may enter a EMM-IDLE mode on the RRC connections.

[0389] Typically, the MME may run a mobile/UE reachable timer with a similar value to the IJE's periodic TAU timer. If this timer may expire in the M ME, the MM E may deduce that the UE may be Out of coverage' at that moment. However, the MME may not know for how long the UE may have been or may be out of coverage and, as such, the M ME may not immediately delete the UE's bearers. Instead the MME may clear a PPF flag in the MME and may start an Implicit Detach timer. With the PPF clear, the MME may not page the UE in E-UTRAN coverage and may send a Downlink Data Notification Reject message to the Serving GW (e.g. the SGW) when receiving a Downlink Data Notification message from the Serving GW. If the Implicit Detach timer may expire before the UE contacts the network, the MME may deduce that the UE may have been or may be Out of coverage' for a long period of time and implicitly detach the UE.

[0390] The MME may stop a mobile/UE reachable timer when a NAS message may be received from the UE on a RRC/'Sl interface and the MME may cancel Implicit Detach timer, for example, when a NAS message may be received from the UE on a RRC/Sl interface.

[0391] A HSS may also be impacted (e.g. to support multiple RRC connections). For example, the MME may download subscription data from the HSS. The Subscription-Data AVI⁵ may include or have BWM-Flag that may be set to 0 by default. Modified S6a messages may also be used such as a S6a:Insert Subscriber Data Request and/or S6a:Update Location Answer. In embodiments, the BWM-Flag AVP may be of type Unsigned32 and it may include a bit mask. The bits that may be included therein may be shown and described in Table 26.

Table 26: BWM-Flag

[0392] In example embodiments, the SGW and PGW may also be impacted as described herein,

[0393] FIG. 84A depicts a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wire! ess bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single- carrier FDMA. (SC-FDMA), and the like,

[0394] As shown in FIG. 84 A, the communications system 100 may include wireless transmit/receive units (WTRXJs) 102a, 102b, 102c, and/or 102d (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, and/or 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, and/or 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0395] The communications systems 100 may also include a base station 114a and a base station 114b. Each of the base stations 1 14a, 114b may be any type of device configured to wirelessiy interface with at least one of the WTRUs 102a, 102b, 102c, and/or 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 1 10, and/or the networks 112. By way of example, the base stations 1 14a and/or 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 1 14b may include any number of interconnected base stations and/or network elements.

[0396] The base station 1 14a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 1 14a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 1 14a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 1 14a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the ceil.

[0397] The base stations 114a and/or 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, and/or 102d over an air interface 115/116/117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 115/116/117 may be established using any suitable radio access technology (RAT).

[0398] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103/104/105 and the VV RXJs 102a, 102b, and/or 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/1 16/1 17 using wideband CDMA (WCDMA).

WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA),

[0399] in another embodiment, the base station 1 14a and the WTRUs 102a, 102b, and/or 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E- UTRA), which may establish the air interface 115/116/1 17 using Long Term Evolution (LTE) and/or LTE- Advanced (LTE -A),

[0400] In other embodiments, the base station 114a and the WTRUs 102a, 102b, and/or 102c may implement radio technologies such as IEEE 802.16 (i.e.. Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 I X, CDM.A2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0401] The base station 114b in FIG. 84A may be a wireless router. Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a pl ace of business, a home, a vehicl e, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802, 15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular- based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 84 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106/107/109.

[0402] The RAN 103/104/105 may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, and/or 102d. For example, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 84A, it will be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UT A radio technology, the core network

106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0403] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, and/or 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PST 108 may include circuit-switched telephone networks that provide plain old telephone sendee (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP IP internet protocol suite. The networks 1 12 may include wired or wireless

communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.

[0404] Some or all of the WTRUs 102a, 102b, 102c, and/or 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, and/or 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 84A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 1 14b, which may employ an IEEE 802 radio technology,

[0405] FIG. 84B depicts a system diagram of an example WTRU 102. As shown in FIG. 84B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touehpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 1 14b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. 84B and described herein.

[0406] The processor 1 18 may he a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller,

Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the

transmit/receive element 122. While FIG, 84B depicts the processor 118 and the transceiver 120 as separate components, it may be appreciated that the processor 1 18 and the transceiver 120 may be integrated together in an electronic package or chip.

[0407] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 1 15/1 16/1 17. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals, in another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0408] In addition, although the transmit/receive element 122 is depicted in FIG. 84B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 1 15/1 16/1 17.

[0409] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.1 1 , for example.

[0410] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. in addition, the processor 1 18 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0411 ] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0412] The processor 1 18 may also be coupled to the G PS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0413] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0414] FIG. 84C depicts a system diagram of the RAN 103 and the core network 106 according to an embodiment. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 84C, the RAN 103 may include Node-Bs 140a, 140b, and/or 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface 115. The Node-Bs 140a, 140b, and/or 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a and/or 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0415] As shown in FIG. 84C, the Node-Bs 140a and/or 140b may be in communication with the RNC 142a. Addition ally, the Node-B 140c may be in communication with the RNC142b. The Node-Bs 140a, 140b, and/or 140c may communicate with the respective RNCs 142a, 142b via an tub interface. The RNCs 142a, 142b may be in communication with one another via an lur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node- Bs 140a, 140b, and/or 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other fu ct onality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0416] The core network 106 shown in FIG. 84C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0417] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an fuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices.

[0418] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an luPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet 1 10, to facilitate communications between and the WTRUs 102a, 102b, and/or 102c and IP-enabled devices.

[0419] As noted above, the core network 106 may also be connected to the networks 1 12, which may include other wired or wireless networks that are owned and/or operated by other se dee providers.

[0420] FIG. 84D depicts a system diagram of the RAN 104 and the core network 107 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface 1 16, The RAN 104 may also be in communication with the core network 107.

[0421] The RAN 104 may include eNode-Bs 160a, 160b, and/or 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, and/or 160c may each mclude one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface 1 16. In one embodiment, the eNode-Bs 160a, 160b, and/or 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0422] Each of the eNode-Bs 160a, 160b, and/or 160c may be associated with a particular cel l (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 84D, the eNode-Bs 160a, 160b, and/or 160c may communicate with one another over an X2 interface.

[0423] The core network 107 shown in FIG, 84D may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator. [0424] The MME 162 may he connected to each of the eNode-Bs 160a, 160b, and/or 160c in the RAN 104 via an S I interface and may serve as a control node. For example, the MM E 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and/or 102c, bearer activatiori/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and/or 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0425] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and/or 160c in the RAN 104 via the S I interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, and/or 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, and/or 102c, managing and storing contexts of the WTRUs 102a, 102b, and/or 102c, and the like.

[0426] The serving gateway 164 may also be connected to the PD gateway 166, which may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet 1 10, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and IP-enabled devices.

[0427] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-swi ched networks, such as the PSTN 108, to facilitate communications between the W RUs 102a, 102b, and/or 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, and/or 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0428] FIG. 84E depicts a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access sendee network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface 1 17. As wi ll be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, and/or 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0429] As shown in FIG. 84E, the RAN 105 may include base stations 180a, 180b, and/or 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, and/or 180c may each be associated with a particular ceil (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface 117. In one embodiment, the base stations 180a, 180b, and/or 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, and/or 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of sendee (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0430] The air interface 1 17 between the WTRUs 102a, 102b, and/or 102c and the RAN 105 may be defined as an R l reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and/or 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, and/or 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.

[0431 ] The communication link between each of the base stations 180a, 180b, and/or 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, and/or 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associ ated with each of the WTRU s 102a, 102b, and/or 102c.

[0432] As shown in FIG. 84E, the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0433] The MIP-HA may be responsible for IP address management, and may enable the W RUs 102a, 102b, and/or 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may faciiitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, and/or 102c with access to the networks 1 12, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0434] Although not shown in FIG. 84E, it should and/or may! be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, and/or 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[0435] Although the terms UE or WTRU may be used herein, it may and should be understood that the use of such terms may be used interchangeably and, as such, may not be distinguishable.

[0436] Additionally, although features and elements are described above in particular combinations, one of ordinary skil l in the art wil l appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer readable medium for execution by a computer or processor.

Examples of non-transistory computer-readable storage media include, but are not limited to, a read only memory (ROM), random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, temimal, base station, RNC, or any host computer.

Claims

What is claimed is:

1. A method for providing multiple connections, the method comprising:

establishing a first RRC connection;

establishing a second RRC connection ; and

maintaining the first RRC connection and the second RRC connections in parallel.

2. The method of claim 1, wherein the first RRC connection is established between a wireless transmit and receive unit and a first network node and the second RRC connection is established between the wireless transmit and receive unit and a second network node.

3. The method of claim 2, wherein the first network node is a first eNB and the second network node is a second eNB,

4. The method of claim 2, wherein the wireless transmit and receive unit is attached to a core network via the first network node and a first bearer is established between the wireless transmit and receive unit and the core network via the first network node, wherem a second bearer is established between the wireless transmit and receive unit and the core network via the second network node, and wherein no connection exists between the second network node and the core network.

5. The method of claim 4, wherein the core network establishes the second bearer via the second network node using signaling via the first network node.

6. The method of claim 5, wherein the second bearer is modified using signaling via the first network node.

7. The method of claim 1 , wherein the first RRC connection and the second RRC

connection are established between a wireless transmit and receive unit and a network node.

8. The method of claim 7, wherein the network node is an eNB,

9. The method of claim 1, further comprising providing a message to a core network indicating that the first RRC connection and the second RRC connection have been established.

10. The method of claim I , wherein the first RRC connection is associated with a first bearer and the second RRC connection is associated with a second bearer, and wherein the first and second bearers are independent of each other.

11. The method of claim 10, further comprising moving the first bearer associated with the first RRC connection to the second RRC connection.

12. The method of claim 1, further comprising moving at least a portion of an IP flow from the first RRC connection to the second RRC connection.

13. The method of claim 1 , further comprising:

attaching to a core network in response to an attach request after establishing the first RRC connection and the second RRC connection.

14. A wireless transmit and receive unit for providing multiple connections, the wireless transmit and receive unit configured to:

establish a first RRC connection with a first network node;

establish a second RRC connection with a second network node; and

maintain the first RRC¹ connection and the second RRC connections in parallel.

15. The wireless transmit and receive unit of claim 14, wherein the first network node is a first eNB and the second network node is a second eNB.

16. The wireless transmit and receive unit of claim 14, wherein the wireless transmit and receive unit is further configured to provide a message to a core network indicating that the wireless transmit and receive unit has established the first RRC connection and the second RRC connection.

17. The wireless transmit and receive unit of claim 14, wherein the first RRC connection is associated with a first bearer and the second RRC connection is associated with a second bearer, and wherem the first and second bearers are independent of each other,

18. The wireless transmit and receive unit of claim 14, wherein the wireless transmit and receive unit is further configured to request that at least a portion of an IP flow be moved from the first RRC connection to the second RRC connection.

19. A method for providing multiple connections, the method comprising:

establishing, at a wireless transmit and receive unit, a first RRC connection associated with a first bearer;

establishing, at the wireless transmit and receive unit, a second RRC connection associated with a second bearer, wherein the second bearer is independent of the first bearer; and maintaining the first RRC connection and the second RRC connections in parallel.

20. The method of claim 19, wherein the first RRC connection is established with a first network node and the second RRC connection is established with a second network node.

21. The method of claim 19, further comprising providing a message to a network indicating that the wireless transmit and receive unit has established the first RRC connection and the second RRC connection.

22. The method of claim 19, further comprising requesting that the first bearer associated with the first RRC connection be moved to the second RRC connection.

23. The method of claim 19, further comprising:

attaching to a core network in response to an attach request after establishing the first RRC connection and the second RRC connection.