Abstract: In order for making MTC more efficient and/or secure, a base station (20) forming a communication system connects a UE (10) to a core network. A node (50) serves as an entering point to the core network for a service provider, and transmits traffic between the service provider and the UE (10). The node (50) establishes, as a connection to the base station (20), a first connection for directly transceiving messages between the node (50) and the base station (20). Alternatively, the node (50) establishes a second connection for transparently transceiving the messages through a different node (30) that is placed within the core network and has established a different secure connection to the base station (20).

Abstract: A method of performing authentication and authorization in Proximity based Service (ProSe) communication by a requesting device (31) which sends a request of a communication and a receiving device (32) which receives the request from the requesting device (31) and (32), the method including deriving session keys Kpc and Kpi from an unique key Kp at the requesting and receiving devices (31) and (32), using the session keys Kpc and Kpi for ProSe communication setup and direct communication between the requesting and receiving devices (31) and (32), starting the direct communication with the requesting and receiving devices (31) and (32). The key Kpc is confidentiality key and the key Kpi is integrity protection key.

Abstract: There is provided a new message flow for improving security without backhaul connection to an EPC. In this message flow, an NeNB (20) updates PS UE list when an authorized PS UE (10) joins or leaves an Isolated E-UTRAN. Further, The NeNB (20) performs UE authentication based on pre-configured credentials. Further, the NeNB (20) can retrieve information necessary for the UE authentication from another NeNB to which the UE (10) previously attached. The NeNB (20) establish secure connection with the UE (10) based on pre-configured IOPS group key.

Abstract: A method of forming a secure group in ProSe communication includes requesting a service request to a ProSe server from a requesting device (21), the service request indicating a request to communicate with a receiving device (22) from the requesting device (21), performing verification on the requesting and receiving devices (21) and (22) by the ProSe server 24, sending a ProSe Service Result to the requesting and receiving devices (21) and (22) to inform to be allowed a group member, and starting a group security establishment of the group including the requesting and receiving devices (21) and (22)

Abstract: Upon requesting an MME (40) to handover a UE (10) to a Target MeNB (20_2), a Source MeNB (20_1) sends, to the Target MeNB (20_2) through the MME (40), information on one or more SeNBs that are candidates available for dual connectivity under control of the Target MeNB (20_2). The Target MeNB (20_2) configures a Target SeNB (30_2) that is selected based on the information to provide the dual connectivity. Alternatively, the Source MeNB (20_1) sends, to the Target MeNB (20_2), information on a Source SeNB (30_1) that has been used by the Source MeNB (20_1) for the dual connectivity. In this case, the Target MeNB (20_2) skips RRC configuration for the Source SeNB (30_1) upon the control.

Abstract: In order for more effectively supporting a Dedicated Core Network, there is provided a network system including a first node (30) that establishes secure connection with a UE (10) initially attempting to attach to a network, through a radio base station (20), and a second node (40) to which the UE (10) is redirected from the first node (30) through the radio base station (20). Upon the redirection, the first node (30) sends information on the first node (30) itself to the second node (40) through the radio base station (20). The second node (40) uses the information to retrieve security context necessary for establishing the connection with the UE (10) from the first node (30).

Abstract: Upon receiving a triggering message from a MTC server (20), a network (10) verifies if the MTC server (20) is authorized to trigger a target MTC device (30) and also if the MTC device (30) is authorized to respond the triggering message, by comparing an MTC device ID and MTC server ID (and optionally information on subscription) which are include in the triggering message with authorized ones. Upon succeeding in the verification, the network (10) checks a trigger type included in the triggering message to verify if the triggering message is authorized to be sent to the MTC device (30). Upon succeeding in the check, the network (10) forwards the triggering message to the MTC device (30). The network (10) also validates a response from the MTC device (30), by checking whether the MTC device (30) is allowed to communicate with the addressed MTC server (20).

Abstract: Upon transmitting privacy information to an MTC server (20) via a network (30, 40), an MTC device (10) includes in a message a field to indicate whether the message contains the privacy information, such that the network (30, 40) can perform authorization for the MTC device (10) and server (20). When the MTC device (10) needs to keep connection with the network (30, 40), the MTC device (10) switches off the functionality of provisioning the privacy information, such that the MTC device (10) still can communicate with the network (30, 40). Upon the transmission of privacy information in an emergency case, the MTC device (10) further includes in the message a content to indicate that the MTC device (10) is an emergency device, such that the network (30, 40) verifies whether the MTC device (10) can be used or activated in the emergency case. Optionally, a USIM for emergency-use is deployed in the MTC device (10).

Abstract: A network node (21), which is placed within a core network, receives a message from a transmission source (30) placed outside the core network. The message includes an indicator indicating whether or not the message is addressed to a group of one or more MTC devices attached to the core network. The network node (21) determines to authorize the transmission source (30), when the indicator indicates that the message is addressed to the group. Further, the message includes an ID for identifying whether or not the message is addressed to the group. The MTC device determines to discard the message, when the ID does not coincide with an ID allocated for the MTC device itself. Furthermore, the MTC device communicates with the transmission source (30) by use of a pair of group keys shared therewith.

Abstract: A network node (21), which is placed within a core network, stores a list of network elements (24) capable of forwarding a trigger message to a MTC device (10). The network node (21) receives the trigger message from a transmission source (30, 40) placed outside the core network, and then selects, based on the list, one of the network elements to forward the trigger message to the MTC device (10). The MTC device (10) validates the received trigger message, and then transmits, when the trigger message is not validated, to the network node (21) a reject message indicating that the trigger message is not accepted by the MTC device (10). Upon receiving the reject message, the network node (21) forwards the trigger message through a different one of the network elements, or forwards the reject message to transmission source (30, 40) to send the trigger message through user plane.

Abstract: An SeNB informs an MeNB that it can configure bearers for the given UE. At this time, the MeNB manages the DRB status, and then sends a key S-KeNB to the SeNB. The MeNB also sends a KSI for the S-KeNB to both of the UE and the SeNB. After this procedure, the MeNB informs an EPC (MME and S-GW) about the new bearer configured at the SeNB, such that the S-GW 50 can start offloading the bearer(s) to the SeNB 30. Prior to the offloading, the EPC network entity (MME or S-GW) performs verification that: 1) whether the request is coming from authenticated source (MeNB); and 2) whether the SeNB is a valid eNB to which the traffic can be offload.

Abstract: In order for efficiently managing communications between a UE (10) and multiple SCSs (20_1-20_n), the UE (10) includes, in one message, multiple pieces of data to be transmitted to the SCSs (20_1-20_n), and sends the message to an MTC-IWF (30). The MTC-IWF (30) receives the message from the UE (10), and distributes the date to the SCSs (20_1-20_n). Each of the SCSs sends (20_1-20_n), to the MTC-IWF (30), data to be transmitted to the UE (10) and an indicator that indicates for the SCSs (20_1-20_n) the time tolerance until the data is transmitted to the UE (10). The MTC-IWF (30) receives the data and the indicators from the SCSs (20_1-20_n), and determines when to forward the data to the UE (10) based on the indicators.

Abstract: A UE (10) provides information on potential S?eNB(s). The information is forwarded from an MeNB (20_1) to an M?eNB (20_2) such that the M?eNB (20_2) can determine, before the handover happens, whether the M?eNB (20_2) will configure a new SeNB (S?eNB) and which S?eNB the M?eNB (20_2) will configure. In one of options, the MeNB (20_1) derives a key S?-KeNB for communication protection between the UE (10) and the S?eNB (30_1), and send the S?-KeNB to the M?eNB (20_2). In another option, the M?eNB (20_2) derives the S?-KeNB from a key KeNB* received from the MeNB (20_1). The M?eNB (20_2) sends the S?-KeNB to the S?eNB (30_1). Moreover, there are also provided several variations to perform SeNB Release, SeNB Addition, Bearer Modification and the like, in which the order and/or timing thereof can be different during the handover procedure.

Abstract: Upon receiving a triggering message from a MTC server (20), a network (10) verifies if the MTC server (20) is authorized to trigger a target MTC device (30) and also if the MTC device (30) is authorized to respond the triggering message, by comparing an MTC device ID and MTC server ID (and optionally information on subscription) which are include in the triggering message with authorized ones. Upon succeeding in the verification, the network (10) checks a trigger type included in the triggering message to verify if the triggering message is authorized to be sent to the MTC device (30). Upon succeeding in the check, the network (10) forwards the triggering message to the MTC device (30). The network (10) also validates a response from the MTC device (30), by checking whether the MTC device (30) is allowed to communicate with the addressed MTC server (20).

Abstract: A method of performing a secure discovery of devices in ProSe communication by a requesting device (21) and the receiving device (22), including requesting a ProSe service request to a ProSe server (24) from the requesting device, performing verification on the requesting and receiving devices by the ProSe server, performing a discovery procedure by the ProSe server to obtain location information of the receiving device, and sending a ProSe service result to the requesting device. The performing discovery procedure includes sending the ProSe service request to a receiving device, performing source verification to see if the request is from an authorized ProSe server and checking discovery criteria to see whether the discovery criteria should have the requested service by the receiving device, and sending a accept message to the ProSe server, if the performing source verification and the checking discovery criteria are successful.

Abstract: There is provided a solution as to how the authentication and thus the authorization of the webRTC IMS Client can be achieved in the IMS of the mobile network operator. The WIC (20) is using an ID to register with IMS, which may be an IMPU, an IMPI, gGRUU etc. The WIC (20) may be preconfigured by the WWSF (30) with the eP-CSCF (40) address and authentication information, but if not, then this information should be retrieved via the WWSF (30) or from the IMS directly or via other device management procedures e.g. OMA DM. It is further assumed that the subscriber has already a valid webRTC account/membership and this can be validated, authenticated and authorized by the WWSF (30).

Abstract: In order for effectively managing security of ProSe (Proximity based Services) communication, a server forming a communication system monitors locations of a plurality of UEs that are grouped to conduct direct communication with each other. The server manages security of the direct communication based on the locations.

Abstract: In order for effectively ensuring security for direct communication in ProSe, a ProSe Function acquires from a 3rd party root keys for each of UEs to derive a pair of session keys for securely conducting direct communication with different UEs, and distributes the acquired root keys to each of the UEs. Each of the UEs derives the session keys by using one of the distributed root keys. Moreover, a plurality of UEs, which form a communication system, and are allowed to conduct direct communication with each other when the UEs are in proximity to each other, share public keys of the UEs therebetween through a node which supports the direct communication upon successfully registering the UEs with the node. Each of the UEs verifies at least a request for the direct communication by using one of the public keys.

Abstract: In order for charging SDT and MTC device trigger over control plane, there is provided a network node (40) that relays messages over a control plane (T5 and Tsp) between an MTC device (10) and an SCS (50). The network node (40) counts the number of messages successfully relayed, and generates a CDR in accordance with the counted number. The messages are SDT messages delivered from the MTC device (10) to the SCS (50), SDT messages delivered from the SCS (50) to the MTC device (10), or MTC device trigger messages delivered from the SCS (50) to the MTC device (10). The network node (40) transfers the CDR to an OCF (31) or a CDF (32).

Abstract: A protection against an unsolicited communication for an IMS (PUCI) system includes a call session control function (CSCF), and a plurality of PUCE application servers. The PUCI application servers make an evaluation as to whether a communication received from the user equipment is an unsolicited communication; the CSCF makes a decision on routing toward the PUCI application servers based on the evaluation; then, the PUCI application servers execute the routing based on the decision.