Method for ProSe communication, base station and WTRU

Abstract

Disclosed are a method for ProSe communication, a base station, and a WTRU, specifically a method and apparatus for communication using Proximity Service (ProSe). An aggregated maximum bit rate parameter (AMBR) may limit a data rate that one or more ProSe bearers may transmit. A wireless transmit / receive unit (WTRU) may request authorization from a network prior to establishing a ProSe bearer specifying a required quality of service (QoS) or other requirements. Each ProSe bearer may have a respective EPS bearer for supporting service continuity. The WTRU may first evaluate the packet using a ProSe check to determine whether the destination of the packet is a ProSe bearer, and then prioritize one or more packet filters. Embodiments herein may include a method of initiating a communication after a discovery process. Embodiments herein may include a method for maintaining session continuity when switching traffic between an evolved packet system (EPS) bearer and a ProSe bearer.

Description

This application is a divisional application of Chinese patent application No. 202011549250.2, whose application date is October 2, 2015 and entitled “Methods, base stations and WTRU for ProSe communication”, and the application is a divisional application of Chinese patent application 201580054159.4, whose application date is October 2, 2015 and entitled “Methods, base stations and WTRU for ProSe communication”. CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 62 / 059,608, filed October 3, 2014, the contents of which are incorporated herein by reference. Background Art

[0002] For a typical Evolved Packet System (EPS) bearer, once an uplink data packet is received, the Traffic Flow Template (TFT) and packet filters in a wireless transmit / receive unit (WTRU) may evaluate the packet for a match. First, the uplink packet filter in the WTRU with the highest evaluation priority index may evaluate the uplink data packet for a match. If no match is found, then other uplink packet filters may evaluate the uplink data packet according to their evaluation priority indexes for a match.

[0003] This process may continue until a match is found, in which case the data packet may be directed to the EPS bearer associated with the TFT of the matching uplink packet filter. If no match is found, the data packet may be sent via an EPS bearer that is not assigned any uplink packet filter. If all EPS bearers (including the default Evolved Packet System (EPS) bearer for the Packet Data Network (PDN)) are assigned an uplink packet filter, the WTRU may discard the data packet. Figure 2 An example of such a process is shown, for Proximity Services (ProSe), the service may be configured with a ProSe bearer. Summary of the invention

[0004] In one embodiment, a method and apparatus for communicating using ProSe is disclosed. The embodiment may include: establishing a ProSe bearer using at least one aggregate maximum bit rate (AMBR) parameter in a wireless transmit / receive unit (WTRU), wherein the at least one AMBR parameter limits an upper limit on a data rate of the ProSe bearer.

[0005] In one embodiment, disclosed is a method and apparatus for establishing a direct connection between a first wireless transmit / receive unit (WTRU) and a second WTRU by using proximity services (ProSe). The embodiment may include: receiving a final traffic flow template (TFT) for a ProSe bearer from a PDN gateway (PGW) in a wireless network; receiving quality of service (QoS) information for the ProSe bearer from a policy and charging rules function (PCRF); and creating a ProSe bearer in the first WTRU.

[0006] In one embodiment, disclosed is a method and apparatus for communicating between a first wireless transmit / receive unit (WTRU) and a second WTRU using proximity services (ProSe). The embodiment may include: upon discovery of the second WTRU by the first WTRU, verifying whether conditions are met to establish direct communication; and reverting to discovery processing if the conditions are not met.

[0007] In one embodiment, disclosed is a method and apparatus for enabling session continuity in Proximity Services (ProSe) communications when switching traffic from an Evolved Packet System (EPS) bearer to a ProSe bearer. The embodiment may include: sending a request from a ProSe-capable wireless transmit / receive unit to a packet data network (PDN) gateway (PGW), wherein the request includes network address translation (NAT) mapping information for a default bearer and future dedicated bearers; and storing the NAT mapping information locally in a WTRU. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which:

[0009] Figure 1A is a system diagram of an example communication system in which one or more disclosed embodiments may be implemented;

[0010] Figure 1B Yes, you can Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) used within the communication system shown;

[0011] Figure 1C Yes, you can Figure 1A A system diagram of an example radio access network and an example core network used within the communication system shown;

[0012] Figure 2 is an example Traffic Flow Template (TFT) / Packet Filter model in a Wireless Transmit / Receive Unit (WTRU);

[0013] Figure 3is a diagram showing WTRU-eNodeB signaling for Proximity Services (ProSe) bearer establishment;

[0014] Figure 4 is the TFT / packet filter model for WTRU with ProSe bearers;

[0015] Figure 5 is the proposed model to perform ProSe inspection before TFT;

[0016] Figure 6 is a diagrammatic representation of the connection between discovery and communication. DETAILED DESCRIPTION

[0017] The embodiments herein generally relate to wireless communication systems, and more particularly to proximity services (ProSe) used in device-to-device (D2D) communications between wireless transmit / receive units (WTRUs). Figure 1A-6 As shown, the embodiments herein may include ProSe optimization processing for solving the following problems: the network does not participate in ProSe bearer establishment and ProSe data bit rate control; the network does not participate in or lacks WTRU rules to set and select packet filtering rules for filtering IP packets into Evolved Packet System (EPS) bearers and ProSe bearers; the dependency between discovery and communication for one-to-one communication is not defined; and a method for session continuity between the Internet and the ProSe path is not defined.

[0018] Reference now Figure 1A , which shows a diagram of an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may allow multiple wireless users to access the content by sharing system resources including wireless bandwidth. As an example, the communication system 100 may use 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), etc.

[0019] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it should be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network components. Each WTRU 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, the WTRUs 102a, 102b, 102c, 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 phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a consumer electronic device, and the like.

[0020] The communication system 100 may also include a base station 114a and a base station 114b. Each base station 114a, 114b may be any type of device configured to facilitate access to one or more communication networks, such as the core network 106, the Internet 110, and / or other networks 112, by wirelessly interfacing with at least one WTRU 102a, 102b, 102c, 102d. The base stations 114a, 114b may be, by way of example, 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. Although each base station 114a, 114b is depicted as a single component, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network components.

[0021] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network components (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals within a specific geographic area called a cell (not shown). The cell may be further 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 114a may include three transceivers, that is, each transceiver corresponds to a sector of the cell. In another embodiment, the base station 114a may use multiple-input multiple-output (MIMO) technology, and thus multiple transceivers may be used for each sector in the cell.

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

[0023] More specifically, as described above, the communication system 100 may be a multiple access system and may use one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. As an example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. 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).

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

[0025] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio access technologies such as IEEE802.16 (Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-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.

[0026] As an example, Figure 1AThe base station 114b in the example may be a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may use any appropriate RAT to facilitate wireless connectivity in a local area such as a business location, a residence, a vehicle, a campus, or the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless local area network (WLAN) by implementing a radio technology such as IEEE 802.11. In another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a wireless personal area network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell by using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.). Figure 1A As shown, the base station 114b can be directly connected to the Internet 110. Thus, the base station 114b does not need to access the Internet 110 via the core network 106.

[0027] The RAN 104 may be in communication with a core network 106, which may be any type of network configured to provide voice, data, application and / or voice over Internet Protocol (VoIP) services to one or more WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 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 Figure 1A Although not shown, it will be appreciated that the RAN 104 and / or the core network 106 may be in direct or indirect communication with other RANs, and that these RANs may employ the same RAT as the RAN 104 or different RATs. For example, in addition to being connected to the RAN 104, which may employ E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) employing GSM radio technology.

[0028] The core network 106 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer network devices that use a common communication protocol, and the protocol may be the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired or wireless communication 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 use the same RAT as the RAN 104 or a different RAT.

[0029] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities, that is, the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0030] Reference now Figure 1B , which shows a system diagram of an example WTRU 102. Figure 1B As shown, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a numeric keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing components while remaining consistent with the embodiments.

[0031] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, 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 in turn may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, however it should be appreciated that the processor 118 and the transceiver 120 may also be integrated into one electronic component or chip.

[0032] The transmit / receive component 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive component 122 may be an antenna configured to transmit and / or receive RF signals. As an example, in another embodiment, the transmit / receive component 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, the transmit / receive component 122 may be configured to transmit and receive RF and light signals. It should be appreciated that the transmit / receive component 122 may be configured to transmit and / or receive any combination of wireless signals.

[0033] In addition, although Figure 1B 102 as a single component, but the WTRU 102 may include any number of transmit / receive components 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive components 122 (e.g., multiple antennas) for transmitting and receiving radio signals via the air interface 116.

[0034] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers that allow the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

[0035] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a numeric keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data from these components. The processor 118 may also output user data to the speaker / microphone 124, the numeric keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store information in any suitable memory such as the non-removable memory 106 and / or the removable memory 132. The non-removable memory 106 may include a random access memory (RAM), a 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, for example, on a server or a home computer (not shown).

[0036] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control power for use by 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 (Ni-Cd), nickel-zinc (Ni-Zn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0037] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) related to 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 from a base station (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information using any suitable positioning method while remaining consistent with an embodiment.

[0038] The processor 118 may also be coupled to other peripheral devices 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 peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, modules, FM radio units, digital music players, video game console modules, Internet browsers, and more.

[0039] Reference now Figure 1C , which shows a system diagram of an example RAN 104 and an example core network 106 according to one embodiment. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 106.

[0040] The RAN 104 may include eNode-Bs 140a, 140b, 140c, however it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. Each of the eNode-Bs 140a, 140b, 140c may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 140a, 140b, 140c may implement MIMO technology. For example, the eNode-B 140a may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0041] Each eNodeB 140a, 140b, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, uplink and / or downlink user scheduling, etc. Figure 1C As shown, the eNode-Bs 140a, 140b, 140c may communicate with one another over an X2 interface.

[0042] Figure 1C The illustrated core network 106 may include a mobility management entity gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. Although each of the foregoing components are described as being part of the core network 106, it should be appreciated that any of these components may be owned and / or operated by an entity other than the core network operator.

[0043] The MME 142 may be connected to each of the eNode-Bs 140a, 140b, 140c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 142 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, performing bearer activation / deactivation processes, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 142 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.

[0044] The serving gateway 144 may be connected to each of the eNode-Bs 140a, 140b, 140c in the RAN 104 via an S1 interface. The serving gateway 144 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 144 may also perform other functions such as anchoring the user plane during inter-eNode-B handovers, triggering paging processing when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0045] The serving gateway 144 may also be connected to a PDN gateway 146, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0046] The core network 106 may facilitate communications with other networks. For example, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks such as the PSTN 108 to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 106 may include or be in communication with an IP gateway, such as an IP Multimedia Subsystem (IMS) server, which may serve as an interface between the core network 106 and the PSTN 108. In addition, the core network 106 may provide the WTRUs 102a, 102b, 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.

[0047] As described above, conventional ProSe communications have issues that can be optimized. First, the network is not involved in ProSe bearer establishment and ProSe data bit rate control. In some embodiments, ProSe bearers may be configured locally at the WTRU without involvement of the eNB or MME. In addition, in some embodiments, the data rate that should be used by the ProSe bearer is not controlled (as an example, the purpose is to ensure that one WTRU does not overuse available resources, thereby potentially forcing other WTRUs to not use resources for ProSe).

[0048] Another problem may be that the network cannot participate in setting up and selecting the process for filtering IP packets into EPS bearers and ProSe bearers, or there are no WTRU rules for such processing. As described above, a unique priority index may be assigned to each packet filter in the TFT within the WTRU (i.e., the priority of a data packet that passes through a specific packet filter in a specific WTRU). This priority index may be assigned by the PDN Gateway (PGW).

[0049] According to the WTRU 102 internal for the above reference Figure 2 In a similar model to the implementation of the packet filter for the EPS bearer described above, a priority index or priority may be assigned to the packet filter for the ProSe bearer. The priority of the ProSe bearer packet filter may be determined not only relative to other ProSe bearers used by the WTRU 102, but also relative to EPS bearers internal to the WTRU 102. Further, the behavior of the ProSe packet filter may be defined to distinguish ProSe packets from packets traversing the Evolved Packet Core (EPC). In addition, it would be desirable if the ProSe packets were treated the same or similarly when moving a ProSe connection to an EPS connection (or vice versa) for service continuity purposes. Thus, the packet filter may attempt to ensure that such packets are treated the same in either case.

[0050] Another issue may be that there is no defined dependency between the discovery process and the communication process for one-to-one communication. In some embodiments with respect to ProSe, there may be no association between the discovery process and the communication process. Since such ProSe communication is implemented using only a one-to-many broadcast method for a group, a discovery process is not actually necessary. However, if one-to-one communication is desired, then the relationship between the communication process and the discovery process may be enabled so that each WTRU 102 in the one-to-one communication may attempt to ensure that the other WTRU 102 is available before establishing a ProSe connection.

[0051] Another problem may be that there is no defined method for session continuity between the Internet and the ProSe path. In some embodiments of ProSe, session continuity is not supported. However, in some embodiments of ProSe, session continuity is desirable (i.e., a data path needs to be established on the Internet and moved to a direct path, or vice versa).

[0052] If the session is switched from the EPC path to the ProSe path, the application may need to continue to use the initial IP address obtained from the EPC during the PDN link establishment process. The EPS bearer carrying the application traffic may be associated with either only an IPv4 address, only an IPv6 address, or may be dual stack (IPv4v6). If one of the two WTRUs 102 uses IPv4 (and the IPv4 address is not common), then a NAT44 or NAT64 function may be required on the P-GW or other edge firewall or router of the EPC domain. Thus, through the intervening NAT function, the source IP address and port of the packet received by the WTRU 102 is different from the source IP address and port of the packet transmitted by the transmitter WTRU 102. When switching the application traffic to the ProSe path, if there is no NAT in place, then the WTRU may receive packets with different source / destination IP addresses and ports. As a result, the packets will be processed improperly and will not be delivered to the correct socket inside the WTRU 102.

[0053] In one embodiment, network authorization for ProSe bearer establishment and bit rate control may be implemented. In some embodiments with respect to ProSe, the WTRU 102 may require network authorization to use resources for ProSe. In other embodiments, the ProSe bearer may be locally set up within the WTRU 102 without authorization from the network. However, it should be noted that in some network configurations, the WTRU may obtain resources for ProSe only when it requests them from the eNB, which may then provide resource assignments via dedicated signaling.

[0054] Definition and usage of a new ProSe aggregate bit rate are discussed herein. At least one new aggregate bit rate parameter may be implemented on each WTRU 102 to limit (e.g., define an upper limit on) the data rate that may be transmitted on one or more ProSe bearers. As an example, this parameter may be referred to as a WTRU ProSe aggregate maximum bit rate (AMBR) and may serve as an upper limit on the maximum bit rate that may be used by a WTRU for data sent on a ProSe bearer (i.e., the maximum bit rate for data sent directly between WTRUs using ProSe).

[0055] ProSe bearers may be modeled in different ways, and as an example, the bearers may be considered as separate PDN connections. In another example, a set of ProSe bearers may be linked to one PDN connection and optionally to a specific access point name (APN). Depending on how the ProSe bearers are modeled, a parameter similar to the WTRU ProSe AMBR may be defined for each "PDN connection" to which the ProSe bearers are linked. For example, the ProSe APN AMBER may be defined as the maximum bit rate at which the WTRU 102 may perform transmission processing on all ProSe bearers that are linked or may be considered to be linked to a PDN connection with a specific APN (e.g., local to the WTRU 102).

[0056] For example, the WTRU 102 may establish a PDN connection with a PGW. Regardless of whether the APN associated with the connection is a default APN selected by the MME or a dedicated APN selected by the WTRU 102, the APN may be referred to as "APN X". A ProSe APN AMBER may be associated with the APN and may represent the maximum bit rate that can be sent on a ProSe bearer associated or linked to a PDN connection associated with PAN X.

[0057] It should be noted that the WTRU 102 may have more than one PDN connection. For example, the WTRU may have one PDN connection with APN X and another PDN connection with PAN Y. For each PDN (APN), the WTRU 102 may be equipped with a ProSe APN AMBR. Taking two PDN connections as an example, the WTRU 102 may have a "ProSe APN-X AMBR" and a "ProSe APN-Y AMBR" associated with the PDN connection with "APN X" and the PDN connection with "APN Y", respectively. The one or more ProSe APN AMBR parameters may be linked to the WTRU ProSe AMBR parameter, wherein the WTRU ProSe AMBR may be the sum of all ProSe APN AMBRs that the WTRU 102 may have. Thus, the WTRU ProSe AMBR may serve as an upper limit for the sum of all ProSe APN AMBRs that the WTRU 102 may have.

[0058] Alternatively, the maximum bit rate may be defined according to the group or service to which the WTRU 102 belongs or is subscribed.

[0059] It should be noted that the proposed bit rate parameters may be defined for each direction, i.e., uplink (UL) and downlink (DL). Even if the examples or suggestions proposed herein are not associated with directions, the suggestions may apply only to the UL direction, only to the DL direction, or to both the UL and DL directions.

[0060] The use and implementation of the WTRU ProSe aggregate bit rate process is discussed here. The WTRU 102 may be equipped with a ProSe AMBR. The ProSe AMBR may be a WT·RU ProSe AMBR or a WTRU ProSe APN AMBR. The ProSe AMBR may be provided in any non-access stratum (NAS) mobility and / or session management message (e.g., attach accept, activate default EPS bearer request). For example, the WTRU ProSe AMBR and / or WTRU ProSe APN AMBR parameters may be defined in a Home Subscriber Server (HSS) and provided to the MME when the WTRU 102 registers to the system. Alternatively, the MME may be locally configured with these parameters that may be applied to one or more WTRUs 102. The MME may forward these parameters to the WTRU 102 via any NAS message.

[0061] The WTRU 102 may also obtain this information from the ProSe function via the PC3 interface. In this case, the ProSe function may send a message indicating the maximum bit rate (e.g., per group or service) to the WTRU 102 any time the WTRU 102 is in contact with the ProSe function. The WTRU 102 may acknowledge receipt of the parameter using signaling over the PC3 interface.

[0062] The WTRU 102 may enforce the received maximum bit rate parameter when it transmits over a ProSe bearer or a direct connection. In accordance with the received parameters, when the data sent by the WTRU 102 exceeds the limit, the WTRU 102 may report to the network (e.g., to an MME, eNB, ProSe function, other 3GPP node, or application server). Alternatively, when the WTRU 102 exceeds the limit, it may report to the user that it cannot send data for the associated application because the data rate exceeds the limit in accordance with the received parameters. The WTRU 102 may also report the excess data used on the ProSe bearer to any 3GPP node as appropriate. The WTRU 102 may deactivate the ProSe bearer locally, or inform the network that the ProSe bearer has been deactivated, or request deactivation from the network and indicate that the reason is due to excess data. The network (e.g., MME, eNB, ProSe function, etc.) may then either authorize (via NAS, RRC, or PC3 signaling) the use of more data or not authorize the additional data.

[0063] The proposed parameters may also be provided to the eNB via the MME when establishing the context of the WTRU 102. This may be done using any S1AP message, such as a WTRU 102 or UE context establishment request. The eNB may also enforce these parameters when providing resources to the WTRU 102 for direct communication. When these limits are exceeded or reached, the eNB may issue a report to the MME or any other node in the system. The report may be propagated by the MME to the PGW via the SGW. For any excess data used on the ProSe bearers, charging records for the data may be published here. When the ProSe data exceeds the limits defined by the proposed parameters, the eNB may use RRC signaling to inform the WTRU 102 that the data may no longer be transmitted via the restricted ProSe bearer or bearers, as appropriate.

[0064] The network authorization process for ProSe bearer establishment is discussed herein. In some embodiments with respect to ProSe, the WTRU 102 may locally configure the ProSe bearer without any authorization from the network (i.e., without any explicit request to the eNB / MME). It should be noted, however, that a check may be made at the eNB whether the ProSe service is authorized for the WTRU 102. Nonetheless, if this check is passed, there will be no explicit authorization request from the WTRU to the network solely for the purpose of ProSe bearer establishment.

[0065] However, it should be noted that if it is desired to restrict the ProSe bearer to a certain bit rate, and / or if it is desired that the eNB may control or monitor the usage of resources used for ProSe, it may be desirable to seek authorization from the network (e.g., at least from the eNB) when establishing the ProSe bearer. Accordingly, the WTRU 102 may seek network authorization for establishing the ProSe bearer, optionally indicating a required QoS or priority or service associated with the ProSe bearer in this case.

[0066] Reference now Figure 3 , which is a diagram illustrating WTRU-eNB signaling for ProSe bearer establishment. The WTRU 102 may request authorization for ProSe bearer establishment using new or existing RRC messages. In the request, the WTRU 102 may indicate information related to the use of the ProSe bearer, such as, by way of example and not limitation, the requested QoS; the associated priority; whether the use is for one-to-many or one-to-one communications; the group ID that will use the bearer (if appropriate); the service type (e.g., public safety versus non-public safety); one or more security parameters (if appropriate); the ProSe bearer ID; or a target user ID, such as the identity of the peer WTRU 102, a target ProSe WTRU ID, or any ProSe-related ID that may be used to identify the target WTRU 102. It should be noted that all or a subset of such information may be locally configured in the WTRU 102, or the information may be provided to the WTRU 102 via NAS signaling or via PC3 signaling with the ProSe function.

[0067] Upon receiving the request to establish a ProSe bearer, the eNB may check what is allowed in terms of ProSe services for the WTRU 102 by verifying the context of the WTRU 102. For example, the eNB may verify the number of existing ProSe bearers, the ProSe bit rate generated by the WTRU 102, and the services permitted for the WTRU 102 (e.g., the permitted groups with which the WTRU 102 may communicate). The eNB may obtain this information from the MME as part of the WTRU 102 context establishment. Alternatively, the eNB may be configured to have this information on a per-WTRU 102 basis or on a per-destination group ID basis. Furthermore, the same local policy may apply to all WTRUs 102 in the system for which ProSe is permitted. Based on this check and other local policies in the eNB, the eNB may respond with a new or existing message to indicate the result.

[0068] As an example, if the request is accepted, the eNB may send an RRCConnectionReconfiguration request or any other existing or new RRC message to the WTRU 102 to indicate that the ProSe bearer should be established. The eNB may indicate the configuration of the bearer (e.g., mode for PDCP, RLC, priority, bit rate, or any subset of the above parameters). In addition, the eNB may also indicate the identity of the ProSe bearer.

[0069] If the request is rejected, the eNB may send a rejection message indicating the reason for the rejection (e.g., reaching the maximum number of active ProSe bearers), where the message may use any new or existing RRC message, for example. The response from the eNB may include any parameters originally received from the requesting WTRU 102 (e.g., target WTRU ID and / or group ID).

[0070] It should be noted that the message proposed above can also be used to modify the ProSe bearer. The modification may include activating a new ProSe bearer, modifying an existing ProSe bearer, or deactivating an existing ProSe bearer. If the request is to modify or deactivate a ProSe bearer, the WTRU102 may include a ProSe bearer ID. It should be noted that an RRC message may include multiple modification requests regarding multiple ProSe bearers, each of which may have a corresponding ProSe bearer ID. For example, the WTRU 102 may send an RRC message, and in the message it may request to establish a new ProSe bearer and modify an existing ProSe bearer at the same time. Similarly, the eNB may respond with an RRC message including the modification results regarding multiple bearers, where the bearers are identified by ProSe bearer IDs.

[0071] The eNB may send an RRC message to the WTRU 102 at any time to request modification (activation, deactivation or modification) of at least one ProSe bearer, wherein the message may also include relevant parameters for each ProSe bearer. The eNB may include the target WTRU ID / group ID involved in the modification.

[0072] It should be noted that the above proposed messages can also be used for any communication path being optimized, even if the path is not a direct path. For example, if the data path will become a "short cut" on the eNB or any node in the system, the same concept can also be applied.

[0073] In another embodiment, a TFT and associated priorities may be established. The TFT for ProSe may be obtained from the PGW. In this case, if a ProSe direct connection is desired to be established between the first WTRU 102 and the second WTRU 102, the PGW and the Policy and Charging Rules Function (PCRF) may be involved. In order to create a ProSe bearer, the first WTRU 102 needs to send a request to the PGW to obtain the final TFT for the bearer, and it also needs to communicate with the PCRF to obtain the appropriate QoS.

[0074] It may be assumed here that the neighboring WTRUs 102 have discovered each other and, as part of the discovery mechanism, have exchanged their IP addresses and / or ProSe WTRU IDs. In addition, the WTRUs 102 may also negotiate a preferred QoS for such a session.

[0075] To establish a ProSe bearer in this case, the first WTRU 102 (i.e., the source WTRU 102) may send a ProSe bearer request within a NAS message to the MME. The request information may include details about the uplink / downlink IP address and port and the QoS requested for the ProSe bearer. The IP information may also be associated with the second WTRU 102 (i.e., the destination WTRU 102). For example, it may match the IP information (e.g., IP address, port, etc.) exchanged between the WTRUs 102.

[0076] The source WTRU 102 may also include a session / link identifier to allow the MME to identify with which WTRU 102 the ProSe bearer is to be established. One possible method for including the link identifier is for the source WTRU 102 to include its ProSe WTRU ID and the ProSe WTRU ID of the target WTRU 102 with which the connection is to be established.

[0077] The destination WTRU 102 may also establish the ProSe bearer by sending a separate NAS request. The destination WTRU 102 may include the same or similar information as provided in the source WTRU request, such as uplink IP flow, requested QoS, and a link identifier, which may be a WTRU ProSe WTRU ID. In the following procedure, it is assumed that the WTRU 102 belongs to a different Public Land Mobile Network (PLMN), whereby the WTRU 102 may communicate with different MMEs, PGWs, and PCRFs. However, the same concepts apply when the WTRUs 102 belong to the same MME, in which case the same MME will serve both WTRUs 102. Similarly, the same eNB may serve both WTRUs 102 simultaneously.

[0078] It should be noted that both WTRUs 102 may contact the ProSe function to obtain a session ID unique to the pair of WTRUs 102. Each WTRU 102 may then provide the session ID to the MME, and the MME may forward the information to the PGW. Each core network (CN) node may use the session ID / link ID to map the bearer requests originating from the two WTRUs 102.

[0079] Both MMEs (assuming the WTRUs 102 belong to different PLMNs) may send requests (e.g., within a NAS message) to the PDN-GW (PGW) to establish ProSe bearers for both WTRUs 102. Both MMEs may include the link identifier for the ProSe session in their requests.

[0080] Once the request is received, the PGW may send a policy and charging (PCC) rule request to the PCRF. The PCC rule request may include a link identifier and user information. In the case of being between PLMNs, the PCRF may negotiate QoS rules for the ProSe session via a roaming interface and may send PCC rules to the PGW.

[0081] Based on the policy provided by the PCRF, the PGW may construct the ProSe TFT, which may include establishing UL and DL TFTs, and defining the evaluation priority index and QoS of the ProSe bearer. The PGW may then provide this information to the MME. The MME may then send this information to the WTRU 102 via a NAS response message.

[0082] The MME may create a ProSe bearer identity for each ProSe bearer and may forward the request to the eNB. The message may also include a corresponding NAS message, which may also be sent to the WTRU 102 to provide it with the TFT allocated for the ProSe bearer.

[0083] The eNB may establish a ProSe bearer for each WTRU 102 according to the QoS information received from the MME.

[0084] Once such a NAS response is received from the MME, each WTRU 102 may install the ProSe TFT and packet filter as instructed by the NAS message. At this point, the WTRU 102 may consider that the ProSe bearer has been successfully established.

[0085] A method for determining the priority index of the TFT / packet filter associated with the ProSe bearer is discussed herein. In the case where the WTRU 102 uses ProSe bearers, it may use two sets of packet filters: EPS bearer packet filters and ProSe packet filters. The packet filters associated with the EPS bearers linked to the ProSe bearers may be configured by the network. For example, the characteristics or configuration of these packet filters may be provided by the P-GW during the establishment of these EPS bearers or when configuring the ProSe bearers.

[0086] The packet filter associated with the ProSe bearer may be locally configured within the WTRU 102 based on a packet filter parameter, which may be, for example, a priority index for the corresponding EPS bearer received by the WTRU 102. The locally configured packet filter may have a different IP 5-tuple than the EPS bearer packet. This is because the source / destination IP addresses associated with the ProSe packet may be different from the ProSe packet going through the internet or EPS bearer. The priority index of the locally configured packet filter may be the same as the priority index of the corresponding EPS packet filter. This may result in the ProSe packets getting the same priority treatment in a service continuity scenario (i.e. when the connection moves from ProSe to EPS or vice versa).

[0087] Reference now Figure 4 , which shows the TFT / packet filter model for the WTRU 102 with ProSe bearers. Figure 4 An example method for using packet filters within different uplink (UL) TFTs in a ProSe WTRU 102 (ie, a WTRU 102 that includes ProSe bearers and EPS bearers) is shown. Figure 4 The illustrated packet filter / TFT model shows a method where for each ProSe bearer (according to layer 2 source / destination), there is a corresponding EPS bearer in the WTRU 102 that can be used for service continuity purposes (i.e. ProSe to EPS or vice versa). This EPS bearer or its context may be established when the ProSe bearer is established, but it will not be used. If the ProSe traffic moves to the EPS bearer or vice versa, then the EPS bearer can be used for service continuity purposes. Figure 4 In the described scenario, EPS bearer #3 and EPS bearer #1 may be EPS bearers corresponding to ProSe bearer #3 and ProSe bearer #1, respectively.

[0088] The packet filters associated with the EPS bearers linked to the ProSe bearers (i.e., Packet Filter 1a, Packet Filter 1b, and Packet Filter 4b) may be configured by the network. For example, the characteristics or configuration of these packet filters may be received from the PGW during the process of establishing these EPS bearers, or may be received when the ProSe bearers are configured. In the latter case, it is necessary for the WTRU 102 to indicate to the network that the ProSe bearers are being established. This indication may be in the form of a Bearer Resource Command (NAS message) to the MME or a similar NAS message. The MME may then request the P-GW (via the S-GW) to send the parameters of the EPS bearer packet filters. These UL packet filter parameters may then be delivered to the WTRU 102 via a NAS response message.

[0089] The packet filters associated with the ProSe bearers (ProSe bearer #3 and ProSe bearer #1) may be locally configured within the WTRU 102 based on the packet filter parameters. This may be done using the priority indexes received by the WTRU 102 regarding the corresponding EPS bearers (EPS bearer #3 and EPS bearer #1). As described above, the priority index of the locally configured packet filter may be the same as the priority index of the corresponding EPS packet filter (for example, the priority index of the locally configured packet filter #4b may be the same as the priority index of the EPS bearer packet filter #4a).

[0090] As described above, the packet filters may evaluate packets in order starting from the highest priority index to the lowest priority index. However, for a ProSe bearer, it is possible to have two packet filters with the same priority index inside the TFT. This problem can be solved by performing additional checks in the TFT associated with the ProSe bearer (e.g. Figure 4 ProSe Check for TFT 1 and TFT 3 in FIG. 1 ). The ProSe Check may match whether the packet belongs to a ProSe bearer or a regular EPS bearer. If the packet is a ProSe packet, it may be sent to a locally configured ProSe bearer. On the other hand, if the ProSe Check determines that the packet is an Internet or EPS packet, it may be sent to a corresponding EPS packet filter at the same priority level. Further details on the ProSe Check functionality will be further described herein.

[0091] for Figure 4In the scenario described in , if the packet passes the ProSe check in TFT 1, then the packet filter with the highest priority index can evaluate it, and it can flow from the packet filter with the highest priority to the packet filter with the lowest priority index until a match is found. It should be noted that for each TFT with ProSe check, the packet must first pass the ProSe check before being evaluated by the packet filter in that particular TFT.

[0092] Reference now Figure 5 , in an alternative example, shown is an illustration of the proposed model of performing ProSe check before TFT. A ProSe check can be performed once before the packet flows through different packet filters. Based on this check, the packet can flow through the EPS TFT and the packet filter, or through the ProSe TFT and the packet filter. Figure 5 It can be observed that if the ProSe check is false, the packet will only flow through TFT1, TFT2 and TFT3, however, if the ProSe check is true, the packet will pass through ProSe TFT1, ProSe TFT2 and / or ProSe TFT3.

[0093] It should be pointed out that in Figure 5 In the example of , it is optional to have a ProSe TFT / packet filter without any ProSe bearers. Doing so can help ensure that the priority of the ProSe bearers and the corresponding EPS bearers remains the same. As an example, in Figure 5 As can be seen from FIG. 1 , the ProSe packet for ProSe bearer #1 and the EPS packet for EPS bearer #1 will pass the same filter check.

[0094] The ProSe check functionality is described herein. The ProSe check may be based on one or more of the following parameters.

[0095] If a ProSe bearer corresponding to an EPS bearer exists or is configured, then the ProSe inspection can always direct the packet to the ProSe packet filter side. Figure 5 For example, for TFT1 in FIG. 1 , when the ProSe bearer is configured, the packet may always go to packet filter #3b. This assumes that the ProSe bearer context may be deleted in the WTRU 102 when service continuity is required (i.e., moving from ProSe to EPS). The corresponding local packet filter may no longer exist.

[0096] If the source or destination IP address for the ProSe connection is different from the corresponding IP address for the EPS connection, the ProSe check can only evaluate the IP address of the packet. Based on the IP address, it can be decided whether to send the packet to the ProSe packet filter or the EPS bearer packet filter. This check is feasible because in some scenarios, the ProSe IP address can be locally configured / assigned, while the source IP address for the EPS bearer can be assigned by the P-GW.

[0097] If the ProSe application is aware of the service continuity switch from ProSe to EPC and vice versa, the application can indicate that a certain packet is a ProSe packet. The ProSe check can then direct the packet to the ProSe packet filter based on the indication.

[0098] Alternatively, the value of the ProSe check flag may be determined based on one or more configured rules or conditions provided to the WTRU 102. The rules may be static (for example, they may indicate that traffic of certain applications may always be sent over a certain link) or dynamic (for example, they may indicate that all traffic may be rerouted to another link if session continuity is triggered due to a change in link conditions on one link). When one or more of these rules or conditions are met, the WTRU 102 may appropriately reconfigure the ProSe check conditions to route traffic to the ProSe link or the EPC link.

[0099] The rules may be configured using one or more of the following options in the WTRU 102. In the WTRU 102, the rules may be configured using an access network discovery and selection function (ANDSF) and may include routing rules for determining which application traffic type should be transmitted using a specific link. The ANDSF may also be used to configure triggers and configuration parameters associated with the triggers to determine when traffic should be switched from one link to another.

[0100] The rules may be preconfigured in the WTRU 102 or the connection manager.For example, the connection manager may be configured to allow device-to-device (D2D) links to be used only for certain application traffic classes.

[0101] The rules may be configured with a bearer configuration. The triggers that must be met to switch traffic from one link to another and the bearer configuration may be configured in the WTRU 102. For example, in configuring a ProSe bearer, the WTRU 102 may be configured with conditions according to which traffic is switched from a ProSe link to an EPC link.

[0102] The rules may be installed by the ProSe function.During a registration and / or configuration procedure performed by the ProSe function, rules may be installed in the WTRU 102, wherein the rules include the rules as described above for indicating which traffic / application may be sent over which link.

[0103] Another embodiment may include a communication process that is performed after a discovery process. To help ensure that the ProSe communication is successful (e.g., to determine that the WTRU 102 is still in close proximity so that a direct communication session can be conducted), a communication session may be linked to a discovery event. In other words, a successful discovery process may result in a communication process being performed if certain conditions are met. The WTRU 102 may verify that the conditions are met in order to begin a direct communication session, which may include signaling with the network or a peer WTRU 102. If these conditions are not met, the WTRU 102 may trigger a discovery process again in order to establish communications.

[0104] Each WTRU 102 may check at least one condition, such as the location and / or proximity of both WTRUs 102, or a time window during which communication may occur after the discovery process. If the WTRU 102 determines that the location or distance condition is not met, or if the time window expires before communication is established, the WTRU 102 may abort the pending communication session and may retry the discovery process.

[0105] Reference now Figure 6 ,The figure shows a diagram of the connection between discovery processing and communication. Figure 6 An example of an overall process is shown by which each WTRU 102 (WTRU 1 and WTRU 2) (eg, the WTRU 102 initiating the discovery process or the WTRU 102 initiating the communication) may successfully establish a communication session.

[0106] Discussed herein is the process of verifying location and / or distance criteria prior to initiating a communication session (or after initiating the communication session).

[0107] Prior to establishing a direct path or during establishment of a direct path, location information may first be verified, such as the distance required for direct communication at the WTRU 102. For example, the WTRU 102 may begin signaling with a peer WTRU 102 and / or the network to establish a direct path, but before the process is complete, the WTRU 102 may continue to verify its location relative to the location of the peer WTRU 102 that has been previously discovered.

[0108] One or more processes of the ProSe function may be triggered by a match report. The ProSe function may generate the match report if two WTRUs 102 have discovered each other or when a session is initiated for communication on the PC5. Thus, when a WTRU 102 initiates a communication session (or after a communication session has begun), each WTRU 102 involved in the communication may send an indication to the ProSe function to inform it to begin the communication, or to request periodic location updates or to track the distance between the WTRUs 102 involved in the communication. This helps determine whether the session should be handed over to the Internet or if the WTRU 102 is not within the minimum proximity required to perform direct communication, then the session should be terminated. The WTRU 102 may include in the indication the identity of the other WTRU 102 with which the communication session is being conducted.

[0109] Then, the ProSe function may initiate a request for location reporting using, for example, the PC4b interface with both Secure User Plane Location (SUPL) Platforms (SLPs) of all the WTRUs 102 involved in the communication, thereby beginning to retrieve location information of the identified WTRU 102. This process is performed because the WTRU location used for the discovery process may be retrieved from the SLP server and the location may be out of date, not accurate enough, or the proximity may be only temporarily valid. The SLPs may then request to measure the latest detailed location of their respective WTRUs 102.

[0110] The ProSe function may trigger periodic location requests, single or multiple detailed location requests in short intervals, from the SLP and for both WTRUs 102 to determine if the WTRUs 102 are moving out of range. If the WTRUs 102 are found to be moving out of range, the process of establishing communication may be avoided. Alternatively, the ProSe function may send a recommendation to recommend that the WTRUs 102 maintain, suspend or switch the communication based on the location information of the WTRUs 102 or the distance between them.

[0111] If the WTRUs 102 belong to different ProSe functions, the ProSe function of one of the WTRUs 102 (e.g., the WTRU 102 initiating the communication) may contact the ProSe function of the other WTRU 102, which in turn may contact the SLP to obtain the location information of its WTRU 102. The location information response may be propagated back to the first ProSe function as currently implemented for the EPC discovery process.

[0112] As another option, a timer may be used after the discovery process before initiating communication. After the timer, the ProSe function may trigger location reports from both WTRUs 102. If it is found that the location is still within range, the timer may be reset and started again. The timer may be used as a new basis for the location reporting interval. The new location reporting period may be synchronized with the timer so that the latest WTRU location may be provided on the SLP server. As long as both WTRUs 102 are within range, it may be assumed that they can establish communication.

[0113] After communication is established, the WTRU location may be used to maintain session continuity by allowing the ProSe function to measure whether the WTRUs 102 are moving apart while the WTRUs 102 are communicating with each other. The ProSe function may initiate one or more additional discovery requests, during which the two WTRUs 102 may exchange measurements about the quality of their direct communication links (e.g., via PC5). As an example, if the direct link is measured to have degraded beyond a certain level based on the distance between the two WTRUs 102 or other measurement reports, the ProSe function may revert to the EPS bearer.

[0114] The use of a time window to protect communication establishment after a discovery event is further discussed herein. In one example, a timer may be started on each WTRU 102. In another example, the timer may be started on a WTRU 102 that discovers a peer WTRU with which it wishes to establish a direct path. The length of the timer may define an interval in which a communication session or direct path should be established before another discovery process needs to be performed. If such a timer is used, then the WTRU 102 may establish a ProSe communication path with its peer WTRU 102 as long as the time has not expired. However, once the timer expires, if the communication path has not been established, the WTRU 102 may abort the process and may restart the discovery process.

[0115] The length of the timer may be locally configurable at the WTRU 102, for example per application, per destination address, or per group to which the WTRU 102 belongs. Alternatively, the ProSe function may provide the timer value for each WTRU 102. For example, the timer may be provided by the ProSe function and may be included in a match report reply sent to the WTRU 102. For the ProSe discovery process at the EPC level, the timer may also be managed by the ProSe function and may be introduced in a proximity alert message sent to the WTRU 102 after proximity is detected.

[0116] The process for determining which conditions should be checked is further discussed herein. The location (or distance) and time window conditions discussed herein are examples of conditions that may be verified by the WTRU 102 to help ensure that a communication session can be successfully established. However, these examples are not exclusive and are not meant to limit the conditions that may need to be verified. The WTRU may be pre-configured with conditions that require verification based on the service (e.g., public safety versus non-public safety), the group ID required for communication, the target WTRU 102, or other user settings.

[0117] Alternatively, the network (e.g., MME, eNB, or ProSe function) may indicate to the WTRU 102 the conditions to be verified and the values ​​to be used, such as the timer condition values ​​described above. These conditions may be provided on a case-by-case basis. For example, these conditions may vary according to the communication session, or may be the same for all communication sessions. The network may modify these conditions based on local policies or based on failure / success reports sent by the WTRU 102 to the network. The WTRU 102 may send the success / failure rate of establishing a communication path with a peer WTRU 102 (optionally after a discovery event). The WTRU 102 may be configured to perform this processing by the network or based on a local configuration or user setting.

[0118] Another embodiment may involve the implementation of session continuity. The method discussed below may solve the IP address problem described above to enable session continuity when switching application traffic from EPS bearers to ProSe bearers. For the following examples, it may be assumed that a network address translation (NAT) function such as NAT44 or NAT64 resides inside the P-GW.

[0119] For example, a ProSe-capable WTRU 102 may request the P-GW to provide NAT mapping information for all default bearers and future dedicated bearers in a PDN Connection Request message. The request may be indicated using a Protocol Configuration Option (PCO) information element. Later, if the P-GW adds NAT mapping for certain application traffic, it may proactively send the new NAT mapping information to the WTRU 102 in an appropriate EPS Session Management (ESM) message, such as in EPS Bearer Activation or EPS Bearer Modification, and this may use the PCO information element.

[0120] Alternatively, the ProSe-capable WTRU 102 may send such a request using another appropriate ESM message, such as an ESM Information Request, which may carry a PCO information element.

[0121] In another example, the ProSe-capable WTRU 102 may request NAT mapping information only after a handover from EPC to ProSe is triggered. In addition, the WTRU 102 may explicitly indicate the application for which it requested NAT mapping information. Upon receiving the request, the P-GW may return specific NAT mapping information for the application.

[0122] After receiving the NAT mapping information from the P-GW, the WTRU 102 may store the information locally and may update the information based on new information from the P-GW. The NAT mapping information obtained from the P-GW may be used for the local NAT function performed by the WTRU 102 for ProSe traffic.

[0123] Triggers for session continuity are discussed herein. The WTRU 102 may be configured with one or more events to trigger a traffic transition from an EPC link to a D2D link, or vice versa. The example triggers discussed below may be described in conjunction with two or more WTRUs 102 (e.g., WTRU A and WTRU B) participating in an IP communication session. Without loss of generality, the example may be extended to a WTRU 102 participating in multiple IP communication sessions to multiple destinations, each of which may be unicast, multicast, or broadcast.

[0124] The WTRU 102 may be configured to perform session continuity when one or more of the following events are triggered.

[0125] The trigger used may be application based. An application may be associated with a preferred link, and the start or stop of an application may be an event that triggers a session continuity decision. For example, two WTRUs 102 may use a direct D2D link established with each other for an application / traffic, and when a new application / traffic is started, the WTRU 102 may determine whether some or all of the traffic needs to be switched to the EPC link.

[0126] Mobility-based triggers may also be used. When the WTRU 102 detects a change in channel conditions associated with the network, the WTRU 102 may determine that it is necessary to perform session continuity. For example, when its connection to the EPC network is lost or begins to degrade, the WTRU 102 may determine that it is necessary to switch traffic from the EPC link to the D2D link. In some cases, upon detecting this situation, the WTRU 102 may initiate a discovery operation to find a relay WTRU 102, and if a relay WTRU 102 is detected, it may perform session continuity processing to continue to pass application traffic over the relay link.

[0127] If one or more of the above triggers are met, the WTRU 102 may initiate operations for enabling session continuity.

[0128] In one example, the WTRU 102 may reconfigure the application and TFT filters to switch some or all applications / traffic from one link to another. As described above, the WTRU 102 may be configured to perform a "ProSe check" on each incoming packet to determine whether the packet should be sent over the D2D link or the EPC link. In one example, if WTRU A is participating in an IP session with WTRU B over an EPC link, and it detects that WTRU B is within a certain proximity and is capable of D2D, then WTRU A may reconfigure its rules to send all applications destined for WTRU B using the ProSe link. This may be accomplished by appropriately configuring the ProSe check rules.

[0129] In order to perform session continuity, it may be necessary for the WTRU 102 to determine an identifier for sending / receiving messages from the destination WTRU 102 using the other link. The WTRU 102 may initiate an operation to determine configuration parameters for handing over traffic. In one example, the WTRU 102 may perform a query using an identifier on one link in order to determine an identifier to use in another link. For example, if a WTRU 102 communicating with another WTRU 102 via a D2D link determines that the D2D link is no longer available, it may request a new identifier, such as an IP address, by sending a query to a network entity (e.g., a PGW or ProSe function). In one example, the WTRU 102 may send the ProSe WTRU ID and IP address of the destination WTRU 102 over the D2D link, and may request the IP address of the destination WTRU 102 in order to send traffic over the EPC network.

[0130] The WTRU 102 may also need to initiate or modify bearer configuration. In order to switch traffic from one link to another, the WTRU 102 may need to request a new bearer or modify the bearer configuration. For example, the WTRU 102 may need to create a new ProSe bearer to support traffic switching from an EPC link to a D2D link.

[0131] The WTRU 102 may also need to initiate or terminate a PDN connection with the network. For example, to initiate a new ProSe link, the WTRU 102 may need to create a new PDN connection for ProSe with the network.

[0132] The rules and events for session continuity described above may be configured in a variety of ways. For example, the rules may be configured in the WTRU 102 using ANDSF and may include routing rules for determining which type of application traffic should be sent using a particular link. In addition, ANDSF may also be used to configure triggers and configuration parameters associated with the triggers to determine when traffic should be switched from one link to another.

[0133] In another example, the rules may be preconfigured in the WTRU 102 or the connection manager. For example, the connection manager may be configured to only allow the use of D2D links for certain application traffic classes.

[0134] In another example, the rules may be configured with bearer configuration. For a trigger to be satisfied to switch traffic from one link to another, the trigger may be configured in the WTRU 102 along with configuring the bearer. As an example, in configuring a ProSe bearer, the WTRU 102 may be configured with conditions to switch traffic from a ProSe link to an EPC link.

[0135] In another example, the rules may be installed by the ProSe function. During a registration and / or configuration process performed by the ProSe function, the rules may be installed in the WTRU 102, including the rules for which traffic / application may be sent over which link as described above.

[0136] Example

[0137] 1. A method, comprising using proximity service (ProSe) to communicate.

[0138] 2. A communication method using proximity service (ProSe), the method comprising: using at least one aggregate maximum bit rate (AMBR) parameter in a wireless transmit / receive unit (WTRU) to establish a ProSe bearer, wherein the at least one AMBR parameter limits an upper limit on a data rate of the ProSe bearer.

[0139] 3. A method for establishing a direct connection between a first wireless transmit / receive unit (WTRU) and a second WTRU using proximity services (ProSe), the method comprising: receiving a final traffic flow template (TFT) for a ProSe bearer from a PDN gateway (PGW) in a wireless network; receiving quality of service (QoS) information for the ProSe bearer from a policy and charging rules function (PCRF); and creating a ProSe bearer in the first WTRU.

[0140] 4. A method for communicating between a first wireless transmit / receive unit (WTRU) and a second WTRU using proximity services (ProSe), the method comprising: once the first WTRU discovers the second WTRU, verifying whether conditions are met to establish direct communication; and if the conditions are not met, resuming the discovery process.

[0141] 5. A method for enabling session continuity in Proximity Services (ProSe) communications when switching traffic from an Evolved Packet System (EPS) bearer to a ProSe bearer, the method comprising: sending a request from a ProSe-capable wireless transmit / receive unit (WTRU) to a packet data network (PDN) gateway (PGW), wherein the request includes network address translation (NAT) mapping information for a default bearer and future dedicated bearers; and locally storing the NAT mapping information in the WTRU.

[0142] 6. A method according to any of the preceding embodiments, wherein the AMBR parameter comprises a maximum bit rate available to the WTRU for use with all ProSe bearers linked to a packet data network (PDN) connection having a specific access point network (APN).

[0143] 7. The method according to any of the preceding embodiments further includes defining a first AMBR parameter for uplink communication and a second AMBR parameter for downlink communication.

[0144] 8. A method according to any of the preceding embodiments, wherein the AMBR parameter is provided to the WTRU by a wireless network.

[0145] 9. The method according to any of the preceding embodiments further includes: sending a request from the first WTRU to the PGW, wherein the request includes Internet Protocol (IP) information for the ProSe bearer.

[0146] 10. The method according to any of the preceding embodiments further includes: the second WTRU sending a ProSe bearer request to the wireless network.

[0147] 11. A method according to any of the preceding embodiments, wherein the ProSe bearer is associated with a TFT and / or a packet filter, and the TFT and / or the packet filter is associated with a priority index for evaluating packets received by the first WTRU.

[0148] 12. The method according to any preceding embodiment, wherein the ProSe bearer is associated with a corresponding Evolved Packet System (EPS) bearer for service continuity.

[0149] 13. The method according to any of the preceding embodiments further includes: determining whether the packet received by the first WTRU is sent to the ProSe bearer or the EPS bearer by performing a ProSe check.

[0150] 14. The method according to any of the preceding embodiments further includes: once it is determined that the packet is sent to the EPS bearer, sending the packet to the EPS bearer, wherein the EPS bearer is at the priority level of the ProSe bearer.

[0151] 15. The method as in any preceding embodiment, wherein the ProSe check is performed before a TFT and / or packet filter evaluates the packet.

[0152] 16. The method as in any preceding embodiment, wherein the ProSe check comprises determining whether the packet should be evaluated by a ProSe packet filter or an EPS packet filter based on an IP address of the packet.

[0153] 17. A method according to any of the preceding embodiments, wherein the parameters of the ProSe check are based on rules or conditions provided to the first WTRU.

[0154] 18. A method according to any of the preceding embodiments, wherein the condition includes the location and / or distance between the first WTRU and the second WTRU.

[0155] 19. A method according to any of the preceding embodiments, wherein the location and / or distance is determined by initiating a request for location reporting on a secure user plane location platform (SLP) of at least the first WTRU or the second WTRU.

[0156] 20. The method according to any of the preceding embodiments further comprises: if the condition falls between certain thresholds, restoring the communication to an Evolved Packet System (EPS) bearer.

[0157] 21. A method as in any preceding embodiment wherein the condition is evaluated after a timer expires.

[0158] 22. The method according to any of the preceding embodiments further includes: configuring one or more events for the WTRU, wherein the events trigger the processing of transferring traffic from an evolved packet core (EPC) link to a device-to-device (D2D) link, and vice versa.

[0159] 23. The method according to any of the preceding embodiments, wherein the one or more events include application-based or mobility-based triggers.

[0160] 24. The method according to any preceding embodiment, wherein an aggregate maximum bit rate parameter (AMBR) limits the data rate that can be transmitted by at least one ProSe bearer.

[0161] 25. The method according to any of the preceding embodiments further includes: defining an AMBR for each packet data network (PDN) connection to which the ProSe bearer is linked.

[0162] 26. The method according to any of the preceding embodiments further includes: defining the AMBR as the maximum bit rate that can be sent by the WTRU on all ProSe bearers linked to or considered to be linked to a PDN connection with a specific access point network (APN).

[0163] 27. The method described in any of the preceding embodiments further includes: defining the AMBR of each group to which the WTRU belongs or each service to which the WTRU is subscribed.

[0164] 28. The method according to any of the preceding embodiments further includes: defining an AMBR for uplink (UL) and / or downlink (DL) communications.

[0165] 29. The method according to any of the preceding embodiments further includes: the WTRU seeking to establish and / or modify one or more ProSe bearers from the network.

[0166] 30. The method according to any of the preceding embodiments further includes: sending a message seeking authorization from the network, wherein the message indicates the required quality of service (QoS), service priority, unicast, multicast or broadcast communication, group identifier, service type, security parameters, ProSe bearer identifier and / or target user identifier associated with the ProSe bearer.

[0167] 31. A method according to any of the preceding embodiments, wherein the network determines allowable conditions for ProSe services by verifying the context of the WTRU.

[0168] 32. The method according to any of the preceding embodiments further includes: sending a message to the WTRU for allowing or rejecting the establishment of a ProSe bearer.

[0169] 33. A method according to any of the preceding embodiments, wherein the message authorizing the establishment of a ProSe bearer indicates the configuration of the bearer and / or the identity of the bearer.

[0170] 34. The method according to any of the preceding embodiments further includes the network sending a message to the WTRU requesting modification, activation or deactivation of at least one ProSe bearer.

[0171] 35. The method according to any of the preceding embodiments further includes: a component of the network receiving a message seeking authorization from the network, the component verifying the context of the WTRU, or the component transmitting a message to the WTRU, wherein the network component may include an eNode B (eNB).

[0172] 36. The method according to any of the preceding embodiments further comprises obtaining a service flow template (TFT) from a packet data network gateway (PGW).

[0173] 37. The method according to any of the preceding embodiments further includes the WTRU using a discovery mechanism within a specified range to discover a target WTRU with ProSe capabilities.

[0174] 38. The method according to any of the preceding embodiments further includes: after discovery, the WTRU sends a ProSe bearer request containing information related to the target WTRU to the network.

[0175] 39. The method according to any of the preceding embodiments, wherein the component of the network that receives the ProSe bearer request comprises a mobility management entity (MME).

[0176] 40. The method according to any of the preceding embodiments further includes: the target WTRU sending a ProSe bearer request to the network.

[0177] 41. The method according to any of the preceding embodiments further includes: the MME sends a request to a packet data network gateway (PGW) to establish a ProSe bearer for the WTRU and the target WTRU.

[0178] 42. The method according to any of the preceding embodiments further includes: the PGW sending a policy and charging (PCC) rule request to a PCC rule function (PCRF).

[0179] 43. The method according to any of the preceding embodiments further includes: the PGW constructing a ProSe TFT and / or QoS for ProSe bearer, and providing the information to the MME, and the MME provides the information to the WTRU.

[0180] 44. The method according to any of the preceding embodiments further includes: the MME creating a ProSe bearer identity for each ProSe bearer, and forwarding a ProSe bearer request to an eNB.

[0181] 45. The method according to any of the preceding embodiments further includes: receiving, by the eNB, a ProSe bearer request from the MMW, and establishing a ProSe bearer for the WTRU and / or the target WTRU.

[0182] 46. ​​A method according to any preceding embodiment, wherein each ProSe bearer is associated with a TFT and / or a packet filter, and each TFT and / or packet filter is associated with a priority index.

[0183] 47. A method as in any preceding embodiment, wherein the TFT and / or packet filter associated with the ProSe bearer is not associated with an Evolved Packet System (EPS) bearer.

[0184] 48. The method according to any of the preceding embodiments further includes: configuring a TFT associated with a ProSe bearer inside the WTRU based on a priority index received by the WTRU regarding a corresponding EPS bearer.

[0185] 49. A method according to any of the preceding embodiments, wherein for each ProSe bearer, there is a corresponding EPS bearer that can be used for service continuity.

[0186] 50. The method according to any of the preceding embodiments further includes: using a packet filter and evaluating packets received by the WTRU in order of priority index from maximum to minimum priority.

[0187] 51. The method according to any of the preceding embodiments further comprises: determining whether the packet is destined for a ProSe bearer or an EPS bearer by performing a ProSe check.

[0188] 52. The method as in any preceding embodiment, wherein the ProSe check is performed before evaluation of each packet filter.

[0189] 53. The method as in any preceding embodiment, wherein the ProSe check is performed once before the packet filter performs evaluation to determine whether the packet should be evaluated by the ProSe packet filter or the EPS packet filter.

[0190] 54. The method as in any preceding embodiment, further comprising: evaluating the packet using a ProSe TFT / packet filter not associated with a ProSe bearer.

[0191] 55. The method according to any of the preceding embodiments further comprises: directing the packet to the ProSe packet filter through ProSe inspection if a ProSe bearer corresponding to the EPS bearer exists or is configured.

[0192] 56. The method as in any preceding embodiment, further comprising: evaluating an IP address of the packet by the ProSe inspection to determine whether the packet should be evaluated by a ProSe packet filter or an EPS packet filter.

[0193] 57. The method according to any of the preceding embodiments further comprises: evaluating, by ProSe checking, whether the source or destination IP address used for the ProSe connection is different from the corresponding IP address used for the EPS connection.

[0194] 58. The method according to any of the preceding embodiments further comprises: upon detecting a service continuity switch, an application indicating whether a packet is a ProSe packet.

[0195] 59. The method according to any of the preceding embodiments further includes: determining the value of the ProSe check flag based on at least one static or dynamic rule or condition provided for the WTRU.

[0196] 60. The method described in any of the preceding embodiments further includes: using an access network discovery and selection function (ANDSF) in the WTRU to configure rules, wherein the rules are pre-configured in the WTRU or the connection manager, configured in the WTRU together with the bearer configuration, and / or installed by the ProSe function.

[0197] 61. The method according to any of the preceding embodiments further comprises: associating the communication session with the discovery event.

[0198] 62. The method described in any of the preceding embodiments further includes: evaluating the location and / or distance between WTRUs to determine whether criteria are met before or during establishing a direct path and / or ProSe connection.

[0199] 63. The method according to any of the preceding embodiments further includes: determining the location information of the WTRU by initiating a request for location reporting on a secure user plane positioning platform (SLP) of at least one of the WTRUs.

[0200] 64. The method according to any of the preceding embodiments further includes: determining whether the criterion is met by evaluating the location and / or distance between the WTRUs, and / or determining whether the criterion is met periodically or at a certain time after a direct path and / or ProSe connection is established by evaluating the quality of the communication link.

[0201] 65. A method according to any of the preceding embodiments, wherein if the location, distance or quality does not meet the criteria, the ProSe function reverts the communication to the EPS bearer.

[0202] 66. The method according to any of the preceding embodiments further includes: configuring a timer value for the WTRU to evaluate the location, distance or quality after a certain time or periodically.

[0203] 67. The method according to any of the preceding embodiments further includes: pre-configuring the conditions that must be met for the WTRU to use the ProSe bearer, wherein the conditions may include service type, group identifier, target WTRU, or other user settings.

[0204] 68. A method according to any of the preceding embodiments, wherein the network configures the WTRU with conditions that must be met to use the ProSe bearer.

[0205] 69. The method according to any of the preceding embodiments further includes: the WTRU with ProSe capability requests the PGW to provide network address translation (NAT) mapping information for all default bearers and future default bearers.

[0206] 70. A method according to any of the preceding embodiments, wherein the ProSe-capable WTRU requests NAP mapping information only after a handover from EPC to ProSe is triggered.

[0207] 71. The method according to any of the preceding embodiments further includes: configuring one or more events for the WTRU, wherein the events trigger a transition from an EPC link to a D2D link, and vice versa.

[0208] 72. The method according to any preceding embodiment, wherein the event comprises an application-based trigger and / or a mobility-based trigger.

[0209] 73. A method according to any of the preceding embodiments, wherein rules including which service / application data can be sent via which link are configured using ANDSF, are pre-configured in the WTRU / connection manager, are configured together with the bearer configuration, and / or are installed by the ProSe function.

[0210] 74. A wireless transmit receive unit (WTRU) configured to perform the method as described in any one of embodiments 1-51.

[0211] 75. A computing device configured to perform the method of any one of embodiments 1-51.

[0212] 76. An integrated circuit configured to perform the method as described in any one of embodiments 1-51.

[0213] 77. An e-node (B), a base station (BS) or an access point (AP), configured to perform the method as described in any one of embodiments 1-51.

[0214] 78. Instructions stored on a computer-readable medium, wherein when executed by a processing device, the instructions instruct the processing device to perform the method as described in any of embodiments 1-73.

[0215] Although the features and elements are described above in specific combinations, it will be recognized by those skilled in the art that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein can be implemented in a computer program, software, or firmware that is introduced into a computer-readable medium for operation by a computer or processor. Examples of computer-readable media include electrical signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memory, semiconductor storage devices, magnetic media such as internal hard disk boxes and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any computer host.

Claims

1. A method for communicating using ProSe (ProSe) implemented by a base station, the method comprising: receiving, from a wireless transmit / receive unit (WTRU), a request to establish one or more ProSe bearers with another WTRU; receiving at least one aggregate maximum bit rate (AMBR) parameter from a network entity; as well as An indication is sent to the WTRU, wherein the indication authorizes the WTRU to establish ProSe communications over the one or more ProSe bearers, wherein the indication is based at least on the AMBR.

2. The method of claim 1, wherein the request includes priority information of the one or more ProSe bearers determined by the WTRU. 3 . The method of claim 1 , wherein the request comprises one or more quality of service (QoS) requirements for the one or more ProSe bearers. The method of claim 1 , wherein the request includes information about a communication mode.

5. A base station for wireless communication, the base station comprising: at least one antenna; a transceiver operatively coupled to the at least one antenna; as well as A processor, wherein: The transceiver and the processor are configured to receive a request from a wireless transmit / receive unit (WTRU) to establish one or more proximity services (ProSe) bearers with another WTRU; The transceiver and the processor are further configured to receive at least one aggregate maximum bit rate (AMBR) parameter from a network entity; and The transceiver and the processor are further configured to send an indication to the WTRU, wherein the indication is based on the at least one AMBR parameter, and wherein the indication authorizes the WTRU to establish ProSe communications over the one or more ProSe bearers.

6. The base station of claim 5, wherein the request comprises priority information of the one or more ProSe bearers determined by the WTRU. 7 . The base station of claim 5 , wherein the request comprises one or more quality of service (QoS) requirements for the one or more ProSe bearers. The base station according to claim 5 , wherein the request includes information about a communication mode.

9. A wireless transmit / receive unit (WTRU) configured for proximity services (ProSe) wireless communications, the WTRU comprising: processor; as well as A transceiver, wherein: The processor and the transceiver are configured to send a request to a packet data network (PDN) gateway (PGW), wherein the request is for network address translation (NAT) mapping information of a default bearer and a future dedicated bearer; The processor and the transceiver are further configured to receive NAT mapping information from the PGW; and The processor is further configured to store the NAT mapping information.

10. A method for proximity services (ProSe) wireless communications implemented by a wireless transmit / receive unit (WTRU), the method comprising: Sending a request to a packet data network (PDN) gateway (PGW), wherein the request is for network address translation (NAT) mapping information of a default bearer and a future dedicated bearer; Receiving NAT mapping information from the PGW; as well as The NAT mapping information is stored.

Images