Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W76/00—Connection management
  • H04W76/10—Connection setup
  • H04W76/14—Direct-mode setup
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/30—Managing network names, e.g. use of aliases or nicknames
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
  • H04L65/1066—Session management
  • H04L65/1101—Session protocols
  • H04L65/1104—Session initiation protocol [SIP]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L2101/00—Indexing scheme associated with group H04L61/00
  • H04L2101/30—Types of network names
  • H04L2101/385—Uniform resource identifier for session initiation protocol [SIP URI]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/50—Address allocation
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
  • H04L65/1066—Session management
  • H04L65/1069—Session establishment or de-establishment
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W8/00—Network data management
  • H04W8/26—Network addressing or numbering for mobility support
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W92/00—Interfaces specially adapted for wireless communication networks
  • H04W92/16—Interfaces between hierarchically similar devices
  • H04W92/18—Interfaces between hierarchically similar devices between terminal devices

Definitions

• the present invention generally relates to session initiation for device-to-device communication.
• the present invention relates to session initiation for device-to-device communication in a broadband radio access network environment.
• radio communication systems such as mobile communication systems (like for example GSM (Global System for Mobile Communication) , GPRS (General Packet Radio Service) , UMTS (Universal Mobile Telecommunication System) or the like), efforts are made for an evolution of the radio access part thereof.
• the evolution of radio access networks like for example the GSM EDGE radio access network (GERAN) and the Universal Terrestrial Radio Access Network (UTRAN) or the like
• GERAN GSM EDGE radio access network
• UTRAN Universal Terrestrial Radio Access Network
• improved radio access networks are sometimes denoted as evolved radio access networks (like for example the Evolved Universal Terrestrial Radio Access Network (E- UTRAN) ) or as being part of a long-term evolution (LTE) .
• E- UTRAN Evolved Universal Terrestrial Radio Access Network
• LTE long-term evolution
• LTE Long-Term Evolution according to 3GPP terminology
• any kind of radio access network may likewise be applicable, as long as it exhibits comparable features and characteristics as described hereinafter.
• FIG. 1 shows the architecture of an E-UTRAN system according to Release 8.
• the E-UTRAN system includes eNBs (EUTRAN Node B' s or evolved Node B's), providing the
• the eNBs may be interconnected with each other by means of an X2 interface (X2 Application Protocol) .
• the eNBs are also connected by means of an Sl interface (Sl Application Protocol) to an evolved packet core network, more specifically to a mobility management entity (MME) by means of an Sl-MME interface, as well as to a serving gateway (S-GW) by means of an Sl-U interface.
• MME mobility management entity
• S-GW serving gateway
• FIG. 2 shows the architecture of the E-UTRAN system for 3GPP accesses.
• the EUTRAN access network in addition to the Sl-MME interface shown in Figure 1, there is also shown an Sl-U interface to a serving gateway.
• the serving gateway is interfaced with the MME (SIl interface) , with a serving gateway support node SGSN (S4 interface), with UTRAN (S12 interface), and with a packet data network (PDN) gateway (S5 interface) .
• Serving Gateway and PDN Gateway may belong to the same network node and in that case, S5 is a node-internal interface.
• IMT-Advanced may include device-to-device (D2D) communication to enable new types of services, and flexible spectrum use to increase the spectral efficiency in a multi-operator environment.
• D2D device-to-device
• D2D communication i.e. a direct communication between at least two devices such as e.g. user equipments or terminals, or servers and terminals of any kind, is being dealt with herein.
• D2D device-to-device
• WLAN wireless local area network
• Hiperlan/2 Hiperlan/2
• Tetra fundamental architectures, conditions and requirements underlying such systems essentially differ from those underlying wireless/cellular communication systems. Therefore, cognition on device-to-device (D2D) communication in such systems is not transferable to wireless/cellular communication systems.
• the Local Breakout provides a technique for local connectivity in addition to (or instead of) wide area IP (Internet Protocol) connectivity and setting up of an SAE (System Architecture Evolution) bearer.
• SAE System Architecture Evolution
• the eNodeB is further proposed to contain local scope DHCP (Dynamic Host Configuration Protocol) discovery to find a local gateway to which it can attach the user equipment to. IP connectivity between the user equipment and the local gateway offers the opportunity for the user equipment to make local IP calls inside the local subnet via the local gateway.
• DHCP Dynamic Host Configuration Protocol
• this known Local Breakout technique does not include feasibility for direct device-to-device communication, because IP connectivity and routing happen by/via the local gateway (also referred to as the access router) .
• a method comprising creating an address of a destination device for device-to-device communication to be of a local address format, creating a session initiation request for device-to-device communication using the created local address format of the destination device, and sending the created session initiation request on a control plane to a local serving network node.
• the method comprises sending the created session initiation request using a control plane message to a local network node
• the session initiation request comprises a session initiation protocol invitation message
• control plane message comprises a non-access stratum message
• the method comprises adding a session initiation protocol identifier, - the local address format indicates that the devices for device-to-device communication are located in a common subnet area of a communication network,
• the local address format is a predetermined format of at least one of a network address identifier, an Internet address, an Intranet address, a phone number, a uniform resource identifier, and a uniform resource locator,
• the method comprises establishing a local device-to- device bearer to the destination device upon request from the local network nod, - the local network node is at least one of a network access node such as a base station and a mobility management entity, and/or
• the method is operable at a source device for device- to-device communication.
• a method comprising receiving a control plane message including a session initiation request for device-to-device communication from a local network node, identifying, in the received control plane message, a session initiation protocol identifier, and processing the session initiation request for initiating device-to-device communication with a source device.
• the method comprises establishing a local device-to- device bearer to the source device upon request from the local network node,
• the session initiation request comprises a session initiation invitation message
• control plane message comprises a non-access stratum message
• the method is operable at a destination device for device-to-device communication.
• a method comprising receiving a control plane message including a session initiation request for device-to-device communication, detecting, in the received control plane message, a session initiation protocol identifier, and forwarding the control plane message including the session initiation request for device-to-device communication for another network node.
• control plane message when the control plane message is received from a device, the control plane message is forwarded to a local network node, and when the control plane message is received from a local network node, the control plane message is forwarded to a device,
• control plane message comprises a non-access stratum message
• the method comprises setting up a device-to-device bearer between devices for device-to-device communication upon receipt of a device-to-device bearer set-up request from a local network node
• the local network node is a mobility management entity, and wherein the device is one of a source device and a destination device for device-to-device communication, and/or
• the method is operable at a network access node such as a base station.
• a method comprising receiving a session initiation request on a control plane from a device, detecting, in the received session initiation request, an address of a destination device for device-to-device communication to be of a local address format, resolving the local address format for locating the destination device and searching for the destination device, and delivering a session initiation request for device-to-device communication using the detected local address format of the destination device on a control plane to the destination device.
• the method comprises forwarding the created session initiation request using a control plane message to a local network node,
• the session initiation request comprises a session initiation invitation message
• control plane message comprises a non-access stratum message
• the method comprises identifying the received session initiation request as a session initiation invitation message by means of a session initiation protocol identifier,
• the method comprises issuing a device-to-device bearer set-up request to a local network node, - the the local address format is a predetermined format of at least one of a network address identifier, an Internet address, an Intranet address, a phone number, a uniform resource identifier, and a uniform resource locator, - the local network node is a network access node such as a base station, and wherein the device is one of a source device and a destination device for device-to- device communication, and/or
• the method is operable at a mobility management entity.
• an apparatus comprising a creator configured to create an address of a destination device for device-to-device communication to be of a local address format, a creator configured to create a session initiation request for device-to-device communication using the created local address format of the destination device, and a transmitter configured to send the created session initiation request on a control plane to a local serving network node.
• the transmitter is further configured to send the created session initiation request using a control plane message to a local network node
• the session initiation request comprises a session initiation protocol invitation message
• the control plane message comprises a non-access stratum message
• the apparatus comprises an adder configured to add a session initiation protocol identifier, - the local address format indicates that the devices for device-to-device communication are located in a common subnet area of a communication network,
• the local address format is a predetermined format of at least one of a network address identifier, an Internet address, an Intranet address, a phone number, a uniform resource identifier, and a uniform resource locator,
• the apparatus comprises an establisher configured to establish a local device-to-device bearer to the destination device upon request from the local network node,
• the local network node is at least one of a network access node such as a base station and a mobility management entity, and/or
• the apparatus comprises a source device for device- to-device communication.
• an apparatus comprising a receiver configured to receive a control plane message including a session initiation request for device-to- device communication from a local network node, an identifier configured to identify, in the received control plane message, a session initiation protocol identifier, and a session processor configured to process the session initiation request for initiating device-to- device communication with a source device.
• the session processor is further configured to pass the session initiation request to an application layer for handling device-to-device session initiation,
• the apparatus comprises an establisher configured to establish a local device-to-device bearer to the source device upon request from the local network node,
• the session initiation request comprises a session initiation invitation message
• control plane message comprises a non-access stratum message
• the apparatus comprises a destination device for device-to-device communication.
• an apparatus comprising a receiver configured to receive a control plane message including a session initiation request for device-to- device communication, a detector configured to detect, in the received control plane message, a session initiation protocol identifier, and a transmitter configured to forward the control plane message including the session initiation request for device-to-device communication for another network node.
• the transmitter when the control plane message is received from a device, the transmitter is configured to forward the control plane message to a local network node, and when the control plane message is received from a local network node, the transmitter is configured to forward the control plane message to a device,
• control plane message comprises a non-access stratum message
• apparatus comprises a processor configured to set up a device-to-device bearer between devices for device- to-device communication upon receipt of a device-to- device bearer set-up request from a local network node
• the local network node is a mobility management entity, and wherein the device is one of a source device and a destination device for device-to-device communication, and/or
• the apparatus comprises a network access node such as a base station.
• an apparatus comprising a receiver configured to receive a session initiation request on a control plane from a device, a detector configured to detect, in the received session initiation request, an address of a destination device for device- to-device communication to be of a local address format, a resolver configured to resolve the local address format for locating the destination device and to search for the destination device, and a transmitter configured to deliver a session initiation request for device-tp-device communication using the detected local address format of the destination device on a control plane to the destination device.
• the transmitter is further configured to send the created session initiation request using a control plane message to a local network node
• the session initiation request comprises a session initiation invitation message
• control plane message comprises a non-access stratum message
• the apparatus comprises an identifier configured to identify the received session initiation request as a session initiation invitation message by means of a session initiation protocol identifier
• the apparatus comprises an issuer configured to issue a device-to-device bearer set-up request to a local network node
• the local address format is a predetermined format of at least one of a network address identifier, an Internet address, an Intranet address, a phone number, a uniform resource identifier, and a uniform resource locator
• the local network node is a network access node such as a base station
• the device is one of a source device and a destination device for device-to- device communication, and/or
• the apparatus comprises a mobility management entity.
• a computer program product comprising program code means being arranged, when run on a processor of an apparatus, to perform the method according to the first aspect and/or any development or modification thereto,
• the device-to-device address may include a phone number, a session initiation protocol (SIP) address, or a uniform resource indicator (URI) such as a uniform resource locator (URL), a uniform resource name (URN) or similar.
• SIP session initiation protocol
• URI uniform resource indicator
• URL uniform resource locator
• UPN uniform resource name
• a session initiation process which does not involve a non-local session server network node (e.g. SIP server) on the user plane, but instead includes added functionality to another local network node (e.g. MME) to handle session initiation in a local subnet domain, - the addition of a session initiation (e.g. SIP) handler to a local network node such as an MME so as to enable the local network node such as the MME to handle local D2D session initiation requests,
• a session initiation e.g. SIP
• a switch point to a device (e.g. application and/or software and/or firmware) that creates wide area session (initiation) requests (to the network) differently than D2D session (initiation) requests (i.e. the device switches the message either to the user plane or to the control plane)
• a switch point to a device (e.g. application and/or software and/or firmware) that detects and handles, in addition to wide area session (initiation) requests (from the network), D2D session (initiation) requests (from the network) (i.e. despite of detecting and handling these different requests differently, the device switches the session initiation message equally to the application layer for corresponding handling)
• a switch point to a device (e.g. application and/or software and/or firmware) that creates wide area session (initiation) requests (to the network) differently than D2D session (initiation) requests (i.e. the device switches the message either to the user plane or to the control plane)
• a switch point to a device (e.g. application and/or software
• NAS i.e. non-access stratum
• the network access node e.g. access router, base station, eNodeB, PDN GW, etc.
• the network access node e.g. access router, base station, eNodeB, PDN GW, etc.
• radio resources coordination of D2D resources and e.g. cellular resources
• device-to-device communication includes a direct communication between two or more devices.
• FIG 1 shows the architecture of an E-UTRAN system according to Release 8
• FIG. 2 shows the architecture of the E-UTRAN system for 3GPP accesses
• Figure 3 shows the different entities involved or impacted by device-to-device communication according to an embodiment of the present invention
• Figure 4 shows a schematic flow diagram of a method at a source-side device according to an embodiment of the present invention
• Figure 5 shows a signaling flow chart for session initiation using a global destination address
• Figure 6 shows a signaling flow chart for device-to- device session initiation using a local destination address according to an embodiment of the present invention
• Figure 7 shows an illustration of device connectivity on different protocols according to an embodiment of the present invention
• Figure 8 shows a schematic flow diagram of a method at a device according to an embodiment of the present invention
• Figure 9 shows a schematic flow diagram of a method at a network access node according to an embodiment of the present invention
• Figure 10 shows a schematic flow diagram of a method at a mobility management entity according to an embodiment of the present invention
• Figure 11 shows a schematic flow diagram of a method of device-to-device bearer setup according to an embodiment of the present invention
• Figure 12 shows a schematic flow diagram of a method at a device according to an embodiment of the present invention
• Figure 13 shows a schematic flow diagram of a method at a destination-side device according to an embodiment of the present invention.
• Figure 14 shows a schematic block diagram of different apparatuses and their interworking according to an embodiment of the present invention. Detailed description of embodiments of the present invention
• the present invention and its embodiments are mainly described in relation to 3GPP technologies being used as non-limiting examples for certain exemplary network configurations.
• an LTE (E-UTRAN) radio access network and corresponding standards (Release-8, Release-9, and LTE-Advanced) are used as a non-limiting example in this regard.
• the description of the embodiments given herein specifically refers to terminology which is directly related thereto. Such terminology is only used in the context of the presented non-limiting examples, and does naturally not limit the invention in any way. Rather, any other network configuration or implementation may also be utilized as long as compliant with the features described herein.
• Exemplary embodiments of the present invention enable the initiation of a D2D session in a 3GPP evolved system architecture (SAE) environment.
• SAE evolved system architecture
• Session initiation in the meaning used herein my be understood as an application layer process that may also be called session setup.
• session initiation or setup may be related to IP connectivity, connection management and bearer management processes on the other respective protocol layers.
• the exemplary embodiments provide a flexible approach to set up a D2D session within the 3GPP SAE (e.g. LTE) using a local number or local address format.
• local address format may be based on any conceivable numbering or address scheme. For example, it may be based on a network access identifier (NAI) format or any other Internet address format, such as e.g. SIP URI (Session Initiation Protocol Uniform Resource Identifier) or http URL (Hypertext Transfer Protocol Uniform Resource Locator) or URN (Uniform Resource Name) .
• NAI network access identifier
• SIP URI Session Initiation Protocol Uniform Resource Identifier
• http URL Hypertext Transfer Protocol Uniform Resource Locator
• URN Uniform Resource Name
• the presence in a local scope may refer for example to Internet or Intranet or it may relate to a cell or a group of neighboring cells of a cellular communication system or any kind of subnet area of an underlying communication system (e.g. an access network) .
• the locality of a target or destination device of a D2D communication is determined in relation to a source or originating device of a D2D communication.
• the modification for indicating locality may for example be a specific suffix and/or prefix and/or extension, and/or a keyword, which indicates a valid D2D format.
• an Internet address e.g. IP address
• a phone number with a special suffix or prefix may be used.
• any specifically designed predetermined format modification of a global address or numbering format may be used as local address format, as along as it is suitable for distinguishing between normal (i.e. nonlocal or global) calls and local calls.
• D2D_keyword For any of these known formats, embodiments of the present invention propose some extension for D2D communication purposes.
• This extension may, for illustrative purposes, be of the format NAI.
• D2D or, in more generic terms, of the format: username ⁇ realm.
• D2D_keyword For any of these known formats, embodiments of the present invention propose some extension for D2D communication purposes.
• This extension may, for illustrative purposes, be of the format NAI.
• D2D_keyword for illustrative purposes, be of the format NAI.
• D2D or, in more generic terms, of the format: username ⁇ realm.
• D2D_keyword For any of these known formats, embodiments of the present invention propose some extension for D2D communication purposes.
• This extension may, for illustrative purposes, be of the format NAI.
• Keyword proposals as mentioned above could be of the format : username@realm. D2D username@realm. direct username ⁇ realm. local
• a network access identifier with a specific D2D extension is assumed as a local address format for the following description.
• This exemplary local address format may e.g. be denoted as "NAI. D2D”, and may e.g. take the form "username@LTED2D. direct”.
• Device-to-device (D2D) communications may share the same band(s) used by the underlying communication system, in this case the cellular (e.g. LTE) network.
• the cellular e.g. LTE
• the D2D communication should be controlled and constrained by the cellular network.
• exemplary embodiments of the present invention relate to a case of a D2D mode (including session initiation) with network support.
• the network support may in the case of a cellular network be provided by any network access node such as a base station (BS) or NodeB or an evolved eNodeB.
• the network access node thus supports messaging of the session initiation, connectivity set-up and resource control (e.g. reuse of licensed radio resources) , but is not involved in data transfer. That is, the supporting base station (BS) or NodeB or an evolved eNodeB is only involved on the control plane, and not on the user plane.
• Exemplary embodiments of the present invention relate to session initiation which may exemplarily happen by IP protocols like the Session Initiation Protocol (SIP) .
• the session initiation generally takes place on a local scope, e.g. within a local subnet area of e.g. Internet or Intranet or a cell or group of neighboring cells in a cellular network.
• a local serving network node such as for example a mobility management entity having knowledge of the location of the devices may serve as a session initiation server, i.e. in the case of SIP as a SIP (application) server, for local sessions, i.e. for sessions for local device-to-device calls.
• Session Description Protocol (SDP) messages may be delivered in the context of session initiation. Yet, an embodiment is that SDP and further session control messaging as signaling the media types will happen directly over the D2D bearer once established as a consequence of this session initiation process. Thus, more media components or more sessions could be added by directly communicating over the D2D connection.
• SDP Session Description Protocol
• FIG 3 shows the different entities involved or impacted by device-to-device (D2D) communication according to an embodiment of the present invention.
• D2D device-to-device
• the thus depicted situation exemplarily relates to the case of a cellular network, wherein the illustrated entities belong to a single cell thereof.
• These entities include the devices (D, such as the UEs shown in Figures 1 and 2) .
• Devices D D and D D+ i as well as devices D 1 and D 1+i are engaged in a mutual D2D communication session, respectively.
• a cellular link is active with respect to device D k , and the base station (eNB 12) serves as a network access node to the (non-local) network e.g. Internet.
• eNB 12 serves as a network access node to the (non-local) network e.g. Internet.
• the dashed arrows indicate possible control links, i.e. links on the control plane e.g. for Radio Resource Control (RRC) messaging.
• RRC Radio Resource Control
• An association status with the eNodeB is checked. If associated with the eNodeB, the eNodeB is contacted for permission to engage in D2D communication. If granted, the device engages in the D2D mode with eNodeB support of this eNodeB.
• the device engages in the D2D mode with eNodeB support of the thus scanned eNodeB.
• network (eNodeB) control can be applied.
• eNodeB network control for D2D communication.
• Control operations being available at the eNodeB as such may for example include or being based on at least one of the following:
• control interface for the network access node which is provided by the dashed line links according to Figure 3, at least one of the following control operations may be provided.
• the eNodeB could reserve some (time, frequency, code sequence, spatial) resources to the D2D devices, which they schedule themselves.
• the eNodeB could remain in control of all resource or power allocations.
• the eNodeB could set constraints and operational regime for a D2D link.
• the eNodeB could make one device lead in the D2D communication and grant resources to that node.
• the eNodeB could request measurements.
• One probable measurement could be the D2D link quality. It is to be noted that such measurements depend on the technique selected for the D2D radio interface.
• the eNodeB could cancel a D2D link.
• the eNodeB could re-establish the communication via cellular links.
• the eNodeb could remain passive after just initiating the D2D session.
• the network access node e.g. the base station or eNodeB
• the network access node can identify a call as a D2D call by detecting a local address format, e.g. a specific Network Address Identifier (NAI) format for D2D communications (local number, NAI. D2D), of the destination device for communication.
• NAI Network Address Identifier
• the source device e.g. UEl
• the destination device e.g. UE2
• a session setup request such as e.g. a SIP INVITE message using the local NAI. D2D of UE2.
• a switch point (in case of SIP protocol session initiation a SIP switch point) for the new NAI.
• D2D format e.g. in the device.
• the switch point in the device handles the addresses of local address format differently than the addresses of normal (SIP) addresses.
• FIG. 4 shows a schematic flow diagram of a method at a source-side device according to an embodiment of the present invention.
• This flow diagram refers to the source device originating the session initiation process.
• an exemplary SIP message representing a session initiation (set-up) request message is created, and a corresponding SIP destination address is created depending on user input or selection by service software.
• the further process is to be distinguished whether or not the thus created destination address contains a D2D extension, i.e. whether or not the destination address is of local scope (S401) . If so (i.e. YES in S401), the local address (e.g. NAI.
• S401 local scope
• D2D or, in more generic terms, username@realm.D2D keyword) is used for session initiation taking place over the control plane.
• the local address is used for creating a corresponding request message (S402)
• a control plane (e.g. non-access stratum, NAS) request message is sent locally (S403) to a corresponding service access point (e.g. NAS SAP), and the local address is resolved at a local serving network node such as e.g. a mobility management entity MME (S404), which is thus enabled to search for the destination device.
• the application layer writes the SIP message to the application programming interface (API) for the firmware of the UE, which receives the e.g.
• API application programming interface
• the firmware writes to the NAS SAP, from where the NAS protocol software processes the NAS protocol headers, copies the application data inside the NAS container, and the delivery is handled by the cellular protocols to the MME. Details of these control plane procedures are given in connection with Figure 6 below.
• the non-local global/normal address (e.g. NAI or, in more generic terms, username ⁇ realm) is used for session initiation taking place over the user plane.
• the global address (e.g. username@realm) is used for creating a corresponding request message (S405)
• a user plane request message is sent to a local packet data network (PDN) gateway (GW) (S406) and further to a non-local SIP server (S407) .
• PDN packet data network gateway
• S407 a non-local SIP server
• the application layer writes the SIP message to the application programming interface (API) for the firmware of the UE, which receives the e.g.
• API application programming interface
• SIP INVITE message in API function call in a proper format having the destination username (i.e. SIP level address), and the function call further includes instructions to place this message to the TCP/IP port.
• the firmware identifies what is the TCP port number to open and which IP address to use. Then, the TCP/IP socket or such is openend, and SIP INVITE message is transmitted there in a TCP/IP datagram. Details of these user plane procedures are given in connection with Figure 5 below.
• the device when the device creates local destination address (i.e. a destination address with a D2D extension), it will not use the NAI format and send the request over the user plane (UP), but it will use the NAI. D2D format and send the request e.g. using a Non-Access Stratum (NAS) control plane (CP) message.
• NAS Non-Access Stratum
• CP control plane
• FIG. 5 shows a signaling flow chart for session initiation using a global destination address (URI, URL, URN or such) .
• This user plane procedure for session initiation for non-local communication comprises, the establishment of a radio resource control (RRC) connection between the source device UEl and eNodeB, the set-up of an SAE bearer between the source device UEl and the PDN gateway, the sending of a SIP INVITE message using the global address on the user plane from the source device UEl via the PDN GW to a SIP application server (SIP AS) , the routing of this SIP INVITE message from the PDN GW to the non-local destination device UE2, and the returning of SIP response messages from the destination device UE2 to the source device UEl over the SIP application server.
• the PDN GW acts as the IP level gateway and router, and it does not process the SIP application messages.
• Figure 6 shows a signaling flow chart for device-to- device session initiation using a local destination address (modified URI, URL, URN or such, e.g. the NAI. D2D) according to an embodiment of the present invention.
• a local destination address modified URI, URL, URN or such, e.g. the NAI. D2D
• an internal arrangement of the individual devices UEl and UE2 is indicated using an illustration of an application layer "appl”, a non- access stratum layer “NAS” and a radio resource control layer “RRC”
• an internal arrangement of the eNodeB is indicated using a non-access stratum layer "NAS” and a radio resource control layer "RRC”.
• the local scope comprises the devices UEl and UE2, the eNodeB, the MME and the PDN gateway, while the SIP application server (SIP AS) represents a non-local network node. It may be seen that the entire procedure runs in the local scope, and the SIP server is not involved.
• SIP AS SIP application server
• the actual session initiation procedure takes place as follows.
• RRC radio resource control
• a local NAI. D2D address format of the destination device UE2 is created by the source device UEl e.g. by a user selecting the address format or by the application picking up an address format in preferred order. Then, the source device UEl sends a session set-up request e.g. in the form of a SIP [NAI. D2D, invite] message to the MME. This may e.g. be effected by using a NAS c-Plane message (as shown in the box below the respective SIP INVITE message) , which is forwarded via the eNodeB to the MME. In other words, the application of device UEl does not send the request to the u-Plane port (e.g. TCP/IP port or UDP/IP port) , but it sends it to the NAS service access point (NAS SAP) instead.
• NAS service access point NAS service access point
• a session initiation protocol e.g. SIP
• SIP session initiation protocol
• MME mobility management entity
• NAS messages as message containers
• RRC messages between the UE and the eNB
• Sl Application protocols between the eNB and MME.
• the transport between eNodeB and MME may for example be an IP tunnel.
• the MME acts as a session initiation server functionality (e.g. similar than a SIP server) .
• session initiation messages e.g. SIP messages inside the NAS container containing a SIP protocol identifier
• the MME is provided with a corresponding session initiation handler, e.g. with a SIP handler.
• the SIP handler (which may also be referred to as a "light SIP server") receives the SIP [NAI. D2D invite] message, and knows where to find the destination device UE2 under the mobility management of that MME, if it is in the same subnet or if it is associated to one of the eNodeB' s in the neighborhood.
• the MME knows the (SIP) presence and knows the address information, that is e.g. dynamic Mobile IP addresses, of the devices attached to it.
• the MME may create its own subnet and give new IP addresses from that local subnet scope for source device UEl and destination device UE2. (These IP addresses would serve D2D IP connectivity only.)
• the MME then forwards the SIP [NAI. D2D invite] message to the destination device UE2. This may e.g. be effected by using a NAS c-Plane message (as shown in the box below the respective SIP INVITE message), which is forwarded via the eNodeB to the destination device UE2.
• the destination device UE2 detects, once it receives a NAS message (i.e. a NAS message container containing a SIP message) , from the SIP protocol identifier of that NAS message (i.e. a NAS message container containing a SIP message) , from the SIP protocol identifier of that NAS message (i.e. a NAS message container containing a SIP message) , from the SIP protocol identifier of that
• the destination device UE2 acts on the SIP INVITE message as if it were received from the SIP server on the u-plane, although it was received in the NAS message on the c-plane. Then, the destination device sends a SIP response message to the MME, and the MME forwards the SIP response to source device UEl.
• the MME requests the eNodeB to set up a D2D radio bearer by issuing a D2D radio bearer set-up request.
• the eNodeB sets up the D2D bearer between the source device UEl and the destination device UE2.
• the eNodeB confirms the successful D2D bearer setup to the MME.
• the execution of the D2D radio bearer set-up as such is not covered by the present invention. It may be performed in any conceivable manner, e.g. as shown in Figure 11.
• Figure 11 shows a schematic flow diagram of a method of device-to-device bearer setup according to an embodiment of the present invention.
• IP connectivity may be provided, and a SIP session for D2D communication between UEl and UE2 can be established. After that, D2D data may be directly exchanged between devices UEl and UE2.
• any Session Description protocol or session control may happen on the D2D bearer directly.
• the peer devices may initiate further sessions, terminate sessions or change their parameters and/or media types on that D2D connection directly.
• the session can be initiated without involving a SIP server.
• the additional delay from involving a SIP server can be avoided.
• the eNodeB receives NAS messages and forwards them to the MME, but it does not process application layer messages as SIP.
• the session protocol identifier in the NAS message is actually for the MME to know that the embedded message is SIP. This is needed because MME will receive NAS messages for various purposes, e.g. security and authentication.
• the SIP protocol identifier lets MME pass the SIP message extracted from inside the NAS message to the SIP handler. (Other NAS contents, e.g. authentication, will go to the authentication protocol software) .
• the eNodeB may detect the SIP protocol identifier in the NAS message, so that it knows to pass that part of the NAS message to the MME.
• all NAS messages will go from the UE to the MME without eNodeB actively processing them.
• NAS messages from the MME will go to the UE without eNodeB actively processing them. That is, the eNodeB just delivers the NAS messages (e.g. inside an RRC message container) to the UE.
• the eNodeB itself could process the application layer protocol (SIP) and detect the address format of local scope.
• SIP application layer protocol
• Figure 7 shows an illustration of device connectivity on different protocols according to an embodiment of the present invention. Namely, Figure 7 illustrates the connectivity between different protocol layers at the two above-mentioned devices engaged in D2D communication.
• the session (e.g. SIP) messages are sent from the application layer of the devices.
• the bearer setup is done at the RRC layer, and the IP connectivity is between the IP layers (i.e. TCP/UDP) at the devices.
• IP layers i.e. TCP/UDP
• IP connectivity (previously referred to in the context of the Local Breakout concept) might be preferred even in the D2D communication case (where it is not mandatorily needed) .
• IP connectivity can virtually be established between the peer devices. This means that the MME delivers local scope IP addresses (i.e. D2D IP addresses) to source device UEl and destination device UE2 for D2D communication, but there will be no routing function needed.
• IP addresses for D2D communications are not necessarily needed, because after the set-up the devices directly know the needed Logical Channel ID (LCID) and know the allocated resources for (D2D) communication.
• LCID Logical Channel ID
• D2D allocated resources for
• having IP addresses in use makes the protocol stack and connectivity more consistent to the normal (widea area) operation. This consistency is beneficial in certain operations.
• the virtual IP connectivity can be established by the MME and may be carried inside the control plane (e.g. NAS) messages so that a D2D bearer request message includes IP addresses for source device UEl and destination device UE2 embedded inside the message elements.
• the eNodeB While setting up the D2D bearer, the eNodeB will also inform the devices about their IP addresses inside the embedded control plane (e.g. NAS) message. That is, the source device UEl will get to know its own IP address and the IP address of its peer entity UE2, whom it invited for a (SIP) session. The destination device UE2 will also get to know its own IP address and the IP address of its peer entity UEl. After the setup, the devices have readily available source IP address and destination IP address, D2D bearer identity (D2D BID) and logical channel ID (LCID) available for D2D communications.
• D2D BID D2D bearer identity
• LCID logical channel ID
• the MME may get the IP addresses for D2D communication between source device UEl and destination device UE2 from an assigned local pool (e.g. discovery from a DHCP), or it may itself assign addresses for them as long as they do not conflict with any other IP address in the same subnet, i.e. local scope. While different IP assignment strategies can be used, it is preferable to have a separate pool of addresses available at the MME so that the MME creates and manages its own subnet. According to certain exemplary embodiments of the present invention, the following messages and their respective contents are provided.
• a session invitation message e.g. SIP INVITE
• a new SIP message e.g. named SIP_D2D_invite could be defined.
• the NAI. D2D format can have for example the following format "username@LTED2D. direct” .
• a control plane message e.g. a NAS message, that contains the SIP message [D2D, invite] and that is directed to the MME.
• a protocol identifier e.g. NAS message header
• the IP address fields could be embedded as NAS message fields and not directly as fields of the RRC message.
• IP addresses it is needed to have IP addresses to tell eNodeB as to which devices are involved.
• the UE IDs e.g. S-TMSI (Supporting Temporary Mobile Subscriber identity)
• the IP address fields could be embedded as NAS message fields.
• a D2D bearer setup message concerning radio bearer set-up for D2D communication is needed.
• c-RNTI cell Radio Network Temporary Identifier
• c-RNTI cell Radio Network Temporary Identifier
• c-RNTI cell Radio Network Temporary Identifier
• c-RNTI cell Radio Network Temporary Identifier
• c-RNTI cell Radio Network Temporary Identifier
• c-RNTI cell Radio Network Temporary Identifier
• Bearer ID and logical channel ID for the D2D connection are needed. All of these are given by the eNodeB. It should be noted that multiple D2D bearers may be set up by a single setup message simultaneously, if necessary.
• a D2D Bearer including at least one of bearer ID, c- RNTI, and logical channel ID.
• a local address or number list may be maintained at the MME.
• the local address or number may be a part of subscription information of the devices in the home subscription server (HSS) , from where the MME may fetch it.
• HSS home subscription server
• the MME may store the local number or address temporarily, or may even deliver it to the eNodeB for temporal storing.
• the device connects to another device using the local address format (e.g. the NAI. D2D format), without performing a complete call setup via the external (core) network such as e.g. the Internet.
• the local address format e.g. the NAI. D2D format
• the external (core) network such as e.g. the Internet.
• This option assumes that either the local number or address is used within the network of one operator, or that the local numbers or addresses are stored/registered with the HSS of an operator.
• the source device may get an indication of denial such as e.g. a "D2D connection not possible" message, and it can then alternatively initiate a connection set-up using the normal SIP session set-up and address format, as illustrated in Figure 5 above.
• the available local numbers or addresses in the vicinity of a device can be advertised by the eNodeB as an (operator) service, or they can be printed/displayed on a device with D2D connectivity (e.g. media server) . Thereby, the discovery of local numbers or addresses in a local scope such as a cell may be accomplished.
• the normal/global number or address may be converted to a local number or address.
• IMS IP Multimedia Subsystem
• this may be effected e.g. by a call state control function (CSCF) .
• CSCF call state control function
• the device obtains the local number or address from the CSCF, and it can use that local number or address for subsequent D2D communication attempts.
• the user of the device may store the local addresses in the address book as extensions of the global addresses of the respective contacts. (This may simply be a choice of "allow local calls", and the software knows to convert the address respectively.)
• SIP Session Initiation Protocol
• SIP messaging may include SDP (Session Description Protocol) fields indicating e.g. media types and media formats of the session, i.e. of the traffic to be exchanged in the session .
• SDP Session Description Protocol
• LBO-internal session set-up for D2D communication i.e. D2D mode
• LTE/SAE using a local address format
• LBO Local Breakout
• the MME additionally sets up a local SAE radio bearer between the device and the eNodeB. This set-up may happen at the initial request by the device.
• the eNodeB is further proposed to contain some networking protocols e.g. for local scope DHCP discovery to find a local gateway to which it can attach the device to.
• IP connectivity between the device and the local gateway offers the opportunity for the device to make local IP calls inside the local subnet via the local gateway. Further, it is possible for the device to access the global Internet, if the local gateway has such functionality. This however, may make the local gateway a performance bottleneck.
• the LBO solution does not yet include a D2D communication option, as described hereinbefore. Accordingly, the basic ideas underlying the above- described eNodeB-supported set-up for D2D communication are also applicable to the LBO concept. Namely, the MME may serve the session set-up (because control plane signaling is used) , and may avoid involvement of wide are core network, which makes response times for local calls (including D2D calls) shorter. Thus, the D2D set-up according to embodiments of the present invention may also be implemented within an LBO framework.
• the MME in LBO sets up SAE bearers, but it can not set up the D2D bearer.
• the MME sends a request to the eNodeB to set up a D2D bearer between the devices.
• the eNodeB sets up a D2D radio bearer, which can also be considered as a special SAE level D2D bearer in the SAE bearer model.
• the bearers may be named D2D SAE bearer and D2D radio bearer, but may shortly be called D2D bearers.
• the service data units (SDUs) delivered on the D2D bearer are mapped (one-to-one) to a logical channel with an LCID.
• the LCID is allocated by the eNodeB and is informed to both devices UEl and UE2.
• Figure 8 shows a schematic flow diagram of a method at a device according to an embodiment of the present invention .
• the exemplary method according to Figure 8 may for example be executed at a user equipment UE acting as a source device of D2D communication.
• a destination address for session initiation is created in that it is decided by the user or by the application whether an address of a destination device for device-to-device communication is of a local address format (e.g. NAI. D2D) . If so (i.e. YES in S801b) , a session initiation request (e.g. SIP INVITE) for device- to-device communication using the created local address format of the destination device is created (S802), and the thus created session initiation request (e.g. SIP INVITE) is written to a corresponding service access point of the control plane (e.g.
• a session initiation request e.g. SIP INVITE
• SIP INVITE session initiation request for device- to-device communication using the created local address format of the destination device
• the sending of S804 may comprise a sending of a control plane message such as a NAS message, which is sent to the MME via an eNodeB.
• a session-initiation-protocol identifier e.g. a SIP identifier
• S803 a session-initiation-protocol identifier
• a local device-to-device bearer to the destination device may be established upon a corresponding request from the eNodeB.
• a device-to-device IP connectivity (as a non-limiting example for any kind of traffic transmission connectivity) in S806, and a device-to-device session may finally be established in S807.
• IP connectivity is established between the user equipment and the (non-local) network.
• the previous establishment of IP connectivity is necessary for non-local session initiation. This is because otherwise the user equipment is not able to send any message, to connect to e.g. web services, or in this case to establish a session with another user equipment in non-local scope.
• a session initiation request e.g.
• SIP INVITE using the global/normal address format of the destination device is created, is written to the TCP/IP or UDP/IP port of the user plane, and is sent to the non-local SIP server (S810) .
• S810 non-local SIP server
• S811 a (non-local) session may finally be established e.g. between the present user equipment and another user equipment or between the present user equipment and an Internet Service Provider (ISP) .
• ISP Internet Service Provider
• Figure 9 shows a schematic flow diagram of a method at a network access node according to an embodiment of the present invention.
• the exemplary method according to Figure 9 may for example be executed at a base station (BS) or NodeB or eNodeB acting as a network access node in the local scope of D2D communication.
• BS base station
• NodeB NodeB
• eNodeB acting as a network access node in the local scope of D2D communication.
• a control plane message (e.g. NAS message) including a session set-up request (e.g. SIP INVITE) for device-to-device communication is received from the source device or an MME (depending on the phase of session initiation, cf. Figure 6) .
• the control plane message (e.g. NAS message) is detected, i.e. the message type of the session initiation protocol (SIP) is detected.
• the control plane message (e.g. NAS message) including the session initiation request (e.g. SIP INVITE) for device-to-device communication is forwarded (i.e. delivered) to another local serving network node such as a MME (if received from the source device) or to the destination device (if received from the MME) .
• a session initiation protocol identifier (e.g. a SIP identifier) may be identified in thus received the NAS message embedding the session initiation request (e.g. SIP INVITE), if added thereto in an adding operation at the device side.
• the session initiation request (e.g. SIP INVITE) is transparently passed from the source device through the network access node to the competent local serving network node (e.g. MME) .
• the competent local serving network node e.g. MME
• the direction of passing-through may also be vice versa, i.e. from the competent local serving network node (e.g. MME) through the network access node to the destination device.
• the competent local serving network node e.g. MME
• a device-to-device bearer between the source device and the destination device for device- to-device communication may be set up upon receipt (in S904) of a device-to-device bearer set-up request from the competent local serving network node (e.g. MME) .
• the competent local serving network node e.g. MME
• IP addresses for D2D communication i.e. the own IP address and the peer IP address
• the D2D bearer may be acknowledged to the MME
• the IP addresses may be distributed to the source device and the destination device. That is, IP connectivity may be provided.
• Figure 10 shows a schematic flow diagram of a method at a mobility management entity according to an embodiment of the present invention.
• the exemplary method according to Figure 10 may for example be executed at a local serving network node acting as a mobility management entity (being responsible for devices of a D2D communication.
• a session initiation request (e.g. SIP INVITE) for device-to-device communication is received from a source device.
• the receiving may comprise a receiving of a control plane message (e.g. NAS message) including a session set-up request (e.g. SIP INVITE) from an eNodeB.
• a control plane message e.g. NAS message
• a session set-up request e.g. SIP INVITE
• a session initiation protocol identifier (e.g. a SIP identifier) may be identified in thus received the NAS message embedding the session initiation request (e.g. SIP INVITE), if added thereto in an adding operation at the device side.
• the MME may identify the message as a SIP message to be passed to a SIP handler, and the MME may thus server as a (light) SIP server.
• an address of a destination device for device- to-device communication is detected (by a SIP handler at the MME) in the thus received session set-up request (e.g. SIP INVITE) to be of a local address format (e.g. NAI. D2D) .
• the local address format is resolved for locating the destination device (with a possible help from the HSS) , and the destination device may be searched in the respective subnet (i.e. local scope) .
• the MME acting as (light) SIP server may search the destination device, i.e. its TMSI and/global IP address, so that it can contact the destination device for session initiation, e.g. by a control plane (NAS) message.
• NAS control plane
• INVITE for device-to-device communication is further delivered (S1005) on the control plane to the destination device of D2D communication.
• the delivery of S1005 may comprise a sending of a control plane message such as a NAS message, which is sent to the destination device vie the eNodeB.
• a device-to-device bearer set-up request may be issued to a local serving network node such as an eNodeB acting as network access node.
• the MME can act as a SIP server, search for the peer (i.e. the destination device) in the local subnet scope, create IP addresses for the D2D peer devices, provide IP connectivity between the peers, and request the eNodeB to set up a D2D bearer.
• the MME will forward the SIP message using identifiers of the destination device UE2 (either its TMSI or IP address or both) via the eNodeB to the destination device UE2.
• the eNodeB will set up the bearers, also D2D bearers, and will deliver the IP addresses to UEl and UE2, and the SIP message will reach the destination device UE2, in the embedded NAS message.
• Figure 12 shows a schematic flow diagram of a method at a device according to an embodiment of the present invention .
• the exemplary method according to Figure 12 may for example be executed at a user equipment UE acting as a destination device of D2D communication.
• a session initiation request (e.g. SIP INVITE) for device-to-device communication is received from a MME on the control plane.
• the receiving may comprise a receiving of a control plane message (e.g. NAS message) including a session set-up request (e.g. SIP INVITE) from an eNodeB.
• a control plane message e.g. NAS message
• a session set-up request e.g. SIP INVITE
• a session initiation protocol identifier (e.g. a SIP identifier) may be identified in thus received the NAS message embedding the session initiation request (e.g. SIP INVITE), if added thereto.
• the UE2 may identify the message as a SIP message to be passed to a SIP handler at the application layer.
• the SIP INVITE message is processed as it were received on the user plane. Namely, the SIP INVITE message will be processed to establish the SIP session between UEl and UE2. Further communications about the sessions between UEl and UE2 may happen via the D2D interface.
• a local device-to-device bearer to the destination device may be established upon a corresponding request from the eNodeB.
• a device-to-device IP connectivity (as a non-limiting example for any kind of traffic transmission connectivity) in S1205, and a device-to-device session may finally be established in S1206.
• Figure 12 only illustrates a method in the case of a local D2D session initiation on the control plane according to embodiments of the present invention, i.e. user equipment UE2 acting as a destination device of D2D communication
• the user equipment UE2 may likewise act as destination device of a normal (i.e. global or non-local) communication, i.e. in the case of a non-local session initiation on the user plane.
• the different operations in these two cases are illustrated in Figure 13.
• Figure 13 shows a schematic flow diagram of a method at a destination-side device according to an embodiment of the present invention.
• the device e.g. application and/or firmware and/or software
• the device reads the non-access stratum service access point NAS SAP, to where the NAS protocol software has processed message contents after handling the NAS protocol headers, and it copies (i.e. passes) the application data via the application programming interface (API) to the application software capable of handling session initiation e.g. by way of the Session Initiation Protocol, for further processing (e.g. the SIP INVITE message) .
• the device e.g.
• the application and/or firmware and/or software of the destination device UE2 receives a TCP connection request, and the TCP/IP port is open for the application software.
• the application layer session initiation protocol receives e.g. SIP INVITE message in an API function call from the TCP/IP port.
• Figure 14 shows a schematic block diagram of different apparatuses and their interworking according to an embodiment of the present invention.
• the thus depicted apparatuses may for example be implemented in or by a (source and/or destination) device or user equipment, a base station or an evolved radio access node (e.g. eNodeB) in an evolved broadband radio access network (e.g. LTE, E-UTRAN), and a mobility management entity MME, respectively.
• a device or user equipment, such a base station or an evolved radio access node (e.g. eNodeB), and such a mobility management entity MME represent particular machines on which a corresponding software implementation of the respective embodiments may be stored and/or executed.
• Figure 14 contains four distinct apparatuses (i.e.
• any one of these apparatuses represents an autonomous entity according to respective embodiments of the present invention, while their interworking entirety or any conceivable combination thereof represents a system according to an embodiment of the present invention.
• the solid line blocks are basically configured to perform the respective operations.
• the entirety of blocks is basically configured to perform the methods and operations as described above, respectively.
• the individual blocks are meant to illustrate respective functional blocks implementing a respective function, process or procedure, respectively.
• Such functional blocks are implementation-independent, i.e. may be implemented by means of any kind of hardware or software, respectively.
• the lines/arrows interconnecting individual blocks are meant to illustrate an operational coupling there-between, which on the one hand is implementation- independent (e.g. wired or wireless) and on the other hand may also comprise an arbitrary number of intermediary functional entities not shown.
• the thus depicted source device or user equipment comprises a (software) switch (or in the exemplary SIP case a SIP switch) , a creator and an adder constituting a format handler or in the exemplary SIP case a SIP format handler) , and a transmitter and/or receiver constituting a transceiver TRX.
• the (address format) creator represents means creating an address of a destination device for device-to-device communication to be of a local address format, and for creating a session initiation request (e.g.
• the transceiver represents means for sending the created session initiation request on a control plane to a local serving network node such as e.g. the depicted MME.
• the transceiver may also represent means for sending the created session initiation request using a control plane message (e.g. NAS message) to a local serving network node such as e.g. the depicted eNodeB.
• a control plane message e.g. NAS message
• the adder represents means for adding a session initiation (e.g. SIP) protocol identifier e.g. to a thus created NAS message.
• a D2D bearer establisher (not shown) represents means for establishing a local device-to- device bearer to the destination device upon request e.g. from the eNodeB.
• the various embodiments of the device or user equipment may include, but are not limited to, cellular mobile phones, multimedia devices, communicators, mini- laptops, personal digital assistants (PDAs) having wireless communication capabilities, portable computers having wireless communication capabilities, image capture devices such as digital cameras having wireless communication capabilities, gaming devices having wireless communication capabilities, music storage and playback appliances having wireless communication capabilities, Internet appliances permitting wireless Internet access and browsing, as well as portable units or terminals that incorporate combinations of such functions .
• PDAs personal digital assistants
• portable computers having wireless communication capabilities
• image capture devices such as digital cameras having wireless communication capabilities
• gaming devices having wireless communication capabilities
• music storage and playback appliances having wireless communication capabilities
• Internet appliances permitting wireless Internet access and browsing, as well as portable units or terminals that incorporate combinations of such functions .
• the thus depicted network access node i.e. eNodeB or BS
• the network access node comprises a detector, a transmitter and/or receiver constituting a transceiver TRX (which is depicted as being separated for two transmission directions, which is however only for illustrative purposes) , an identifier, and an D2D bearer processor.
• the detector represents means for detecting, in a received control plane message (e.g. NAS message) , a SIP protocol identifier, and the transceivers represent means for receiving and/or sending a control plane message including a session initiation request for device-to-device communication.
• the transceiver on the left-hand side may represent means for receiving a control plane message including a session initiation request for device-to-device communication (from the source device)
• the transceiver on the right-hand side may represent means for forwarding the control plane message including the session initiation request for device-to-device communication (to the MME) .
• the transceiver on the right-hand side may represent means for receiving a control plane message including a session initiation request for device-to-device communication (from the MME), and the transceiver on the right-hand side may represent means for forwarding the control plane message including the session initiation request for device-to-device communication (to the destination device) .
• the identifier represents means for identifying a session initiation protocol identifier in the control plane message.
• the eNodeB or BS as such may represent means for transparently passing though a session initiation request (e.g. SIP INVITE) between source/destination device and the MME.
• the D2D bearer processor may represent means for setting up a device-to-device bearer between source and destination devices for device-to-device communication upon receipt of a device-to-device bearer set-up request e.g. from the MME.
• the thus depicted local serving network node e.g. the mobility management entity MME, comprises a detector, a resolver and a deliverer and an identifier constituting a handler (or in the exemplary SIP case a SIP handler) , a transmitter and/or receiver constituting a transceiver TRX, and also an D2D bearer issuer.
• the mobility management entity MME comprises a detector, a resolver and a deliverer and an identifier constituting a handler (or in the exemplary SIP case a SIP handler) , a transmitter and/or receiver constituting a transceiver TRX, and also an D2D bearer issuer.
• the transceiver represents means for receiving a session initiation request (e.g. SIP INVITE) on a control plane from the device
• the detector represents means for detecting, in the received session initiation request, an address of a destination device for device-to-device communication to be of a local address format
• the resolver represents means for resolving the local address format for locating the destination device and for searching for the destination device
• the deliverer represents means for delivering a session initiation request (e.g. SIP INVITE) for device- to-device communication further using the detected local address format of the destination device
• the transceiver also represents means for sending it to the destination device.
• the transceiver may also represent means for receiving the session initiation request using a control plane message (e.g. NAS message) from the eNodeB, and/or means for sending the created session initiation request using a control plane message (e.g. NAS message) to a local network node such as e.g. the depicted eNodeB.
• a control plane message e.g. NAS message
• NAS message e.g. NAS message
• the identifier represents means for identifying the received session initiation request as a session initiation protocol invitation message by means of a session initiation protocol identifier in the received NAS message.
• the D2D bearer issuer represents means for issuing a device-to-device bearer set-up request to a local serving network node such as e.g. the depicted eNodeB.
• the thus depicted destination device or user equipment comprises an identifier, a session initiation (e.g. SIP) handler, a transmitter and/or receiver (TRX), and an D2D bearer establisher.
• a session initiation (e.g. SIP) handler e.g. SIP
• TRX transmitter and/or receiver
• D2D bearer establisher e.g. SIP
• the transceiver represents means for receiving a control plane message (e.g. NAS message) including a session initiation request (e.g. SIP INVITE) for device-to-device communication from a local network node.
• a control plane message e.g. NAS message
• a session initiation request e.g. SIP INVITE
• the identifier represents means for identifying, in the received control plane message, a session initiation protocol (SIP) identifier
• the SIP handler represents a session processor or, stated in other words, means for processing the session initiation request for initiating device-to- device communication with a source device, which may include passing the session initiation request to an application (e.g. application layer) for handling device- to-device session initiation.
• an application e.g. application layer
• the D2D bearer establisher represents means for establishing a local device-to-device bearer to the source device upon request from the local network node (similar to that of the source device, although not shown there) .
• a device-to-device communication may equally include three or more devices (i.e. multi-party sessions) .
• one or more of the involved devices may start the multi-party session initiation, while the one or more remaining devices on local scope act as destination devices, respectively.
• respective functional blocks or elements according to above-described aspects can be implemented by any known means, either in hardware and/or software, respectively, if it is only adapted to perform the described functions of the respective parts.
• the mentioned method steps can be realized in individual functional blocks or by individual devices, or one or more of the method steps can be realized in a single functional block or by a single device.
• method steps and functions likely to be implemented as software code portions and being run using a processor at one of the entities are software code independent and can be specified using any known or future developed programming language such as e.g. Java, C++, C, and Assembler.
• the operation system may include linux, unix, Symbian, Windows, Java J2ME etc.
• Method steps and/or devices or means likely to be implemented as hardware components at one of the entities are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS, CMOS, BiCMOS, ECL, TTL, etc, using for example ASIC components or DSP components, as an example.
• any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention.
• Devices and means can be implemented as individual devices, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved. Such and similar principles are to be considered as known to those skilled in the art.
• Software in the sense of the present description comprises software code as such comprising code means for performing the respective functions, as well as software (or a computer program or a computer program product) embodied on a tangible medium such as a computer-readable storage medium having stored thereon a respective data structure or code portions or embodied in a signal or in a chip, potentially during processing thereof.
• an access technology may be any technology by means of which a user equipment can access an access network (e.g. via a base station, access point or generally an access node) .
• Any present or future technology such as WLAN (Wireless Local Access Network) /WiFi, WiMAX (Worldwide Interoperability for Microwave Access) , BlueTooth, Infrared, Ultra Wideband (UWB) and the like may be used; although the above technologies are mostly wireless access technologies, e.g. in different radio spectra, access technology in the sense of the present invention may also imply wirebound technologies, e.g.
• IP based access technologies like cable networks or fixed lines but also circuits switched access technologies; access technologies may be distinguishable in at least two categories or access domains such as packet switched and circuit switched, but the existence of more than two access domains does not impede the invention being applied thereto, - an access network may be any device, apparatus, unit or means by which a station, entity or other user equipment may connect to and/or utilize services offered by the access network; such services include, among others, data and/or (audio-) visual communication, data download etc .
• a user equipment may be any device, apparatus, unit or means by which a system user may experience services from an access network such as a mobile phone, personal digital assistant PDA, multimedia device, communicator, laptop or computer;
• - method steps likely to be implemented as software code portions and being run using a processor at a network element or terminal are software code independent and can be specified using any known or future developed programming language as long as the functionality defined by the method steps is preserved;
• any method step is suitable to be implemented as software or by hardware without changing the idea of the invention in terms of the functionality implemented;
• any method steps and/or devices, apparatuses, units or means likely to be implemented as hardware components at a terminal or network element, or any module (s) thereof are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor-Transistor Logic), etc., using for example ASIC (Application Specific IC (Integrated Circuit) ) components, FPGA (Field-programmable Gate Arrays) components, CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components; in addition, any method steps and/or devices, units or means likely to be implemented as software components may for example be based on any security architecture capable e.g. of authentication, authorization, keying and/or traffic protection;
• any security architecture capable e.g. of authentication
• devices, apparatuses, units or means can be implemented as individual devices, apparatuses, units or means, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device, apparatus, unit or means is preserved,
• an apparatus may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of an apparatus or module, instead of being hardware implemented, be implemented as software in a (software) module such as a computer program or a computer program product comprising executable software code portions for execution/being run on a processor;
• a device may be regarded as an apparatus or as an assembly of more than one apparatus, whether functionally in cooperation with each other or functionally independently of each other but in a same device housing, for example.
• the present invention also covers any conceivable combination of method steps and operations described above, and any conceivable combination of nodes, apparatuses, modules or elements described above, as long as the above-described concepts of methodology and structural arrangement are applicable.
• session initiation for device-to-device communication using a local address format which exemplarily comprises detecting an address of a destination device for device-to-device communication to be of a local address format, creating a session initiation request for device-to-device communication using the detected local address format of the destination device, and sending the created session initiation request on a control plane to a local serving network node.
• features thereof may comprise at least one of:
• the eNodeB optional detection of NAS message with a new session protocol identifier and delivery of NAS message from the source UE to the MME encapsulated in the Sl application protocol or from the MME to the destination UE encapsulated in the RRC message.
• the eNodeB could detect a D2D call directly by detecting a new local NAI format in the session initiation protocol.
• the application software which determines, when and to which calls to use the D2D format and how to create the D2D format, a switch point (e.g. implemented in software) to treat regular connections differently from D2D connections, and/or sending of NAI.
• D2D format messages via NAS messages in the control plane .

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Business, Economics & Management (AREA)
• General Business, Economics & Management (AREA)
• Multimedia (AREA)
• Mobile Radio Communication Systems (AREA)

Applications Claiming Priority (1)

Publications (1)

Family

ID=40551371

Family Applications (1)

Country Status (2)

Cited By (2)

Families Citing this family (36)

Family Cites Families (2)

• 2008
  • 2008-09-12 WO PCT/EP2008/062134 patent/WO2010028690A1/en active Application Filing
  • 2008-09-12 EP EP08804099A patent/EP2324616A1/de not_active Withdrawn

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events