6 Roles for PN-registration
24.2593GPPPersonal Network Management (PNM)Release 17Stage 3TS
6.1 Introduction
The PN-registration is the procedure where a UE is added to the PN, or a PNE is added to the PAN. As a result of a successful registration, the UE capabilities are conveyed to the PNM application.
6.2 PN UE
If a PN UE supports the PN controller functionality and is configured to act as a PN controller the PN UE shall include in the Contact header of the REGISTER request a g.3gpp.iari_ref feature tag containing the IARI value defined in subclause 10.4.
Upon receiving a REGISTER request sent from a PNE other than a PN UE via the PAN internal interface, the PN UE shall initiate a SIP REGISTER request as defined in 3GPP TS 24.229 [3] subclause 5.1.1.2.1 with the following addition:
1) including in the Contact header field a g.3gpp.pne-id media feature tag containing the PNE identifier defined in subclause 6.4.
If using the multiple registrations mechanism for registering each PNE, the PN UE shall use a different "reg-id" value when registering the PNE.
If using SIP re-registration procedures for registering another PNE, the PN UE includes a Contact header field for each registered PNE in the SIP REGISTER request.
There are no PNM specific requirements for registration of the PN UE to the CS domain.
6.3 PNM Application
6.3.1 PN-registration procedure in the IM CN subsystem
The PNM AS can be configured with any of various options for obtaining information from the IM CN subsystem specified in 3GPP TS 24.229 [3], 3GPP TS 29.328 [9] and 3GPP TS 29.329 [12], for example:
a) receipt of REGISTER request which causes a third-party REGISTER request containing in the body the incoming REGISTER request from the PN UE and the 200 (OK) response to the incoming REGISTER request to be sent to the PNM application. The PNM application may then obtain information from the body of the third-party REGISTER request;
b) receipt of REGISTER request which causes a third-party REGISTER request containing in the body a <service-info> element containing the private user identity of the PN UE to be sent to the PNM application. The PNM application may then subscribe to the reg event package for that user to obtain information; or
c) receipt of REGISTER request which causes a third-party REGISTER request containing in the body a <service-info> element containing the private user identity of the PN UE to be sent to the PNM application. The PNM application may then use the Sh interface to obtain information.
This document places no requirement on the use of all or any of these mechanisms.
After successful PN-registration, the PNM AS shall enrol the public user identity of the registered PN UE or the registered PNE identifier in the data base.
6.3.2 PN-registration procedure in the CS domain
When the gsmSCF (CAMEL service for PNM) receives a MAP_NOTE_MM_EVENT message sent from the VLR to report that the status of the UE set to ‘attached’, the gsmSCF sets the UE registration status in the PN to ‘registered’ and sends the UE status to the PNM AS.
NOTE: The interface between the gsmSCF and the PNM AS is unspecified.
When the gsmSCF (CAMEL service for PNM) receives a MAP_NOTE_MM_EVENT message sent from the VLR to report that the status of the UE set to ‘detached’, the gsmSCF sets the UE registration status in the PN to ‘deregistered’ and checks whether the PN UE was the only default UE in the PN. If it was the only default UE in the PN, the gsmSCF generates a USSD Notify message to the HSS to inform the user.
6.4 Definition of media feature tag g.3gpp.pne-id
Media feature-tag name: g.3gpp.pne-id
ASN.1 Identifier: 1.3.6.1.8.2.8
Summary of the media feature indicated by this tag: This media feature-tag when used in a SIP request or a SIP response indicates the identifier of a PNE other than a UE.
Values appropriate for use with this feature-tag: URN. When an IMEI is available, the URN shall take the form of a IMEI URN (see IETF RFC 7254 [22]). If no IMEI is available, the URN shall take the form of a string representation of a UUID as a URN as defined in IETF RFC 4122 [23].
The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature-tag is most useful in a communications application, for describing the capabilities of a device, such as a PC or PDA.
Examples of typical use: Indicating the identifier of a device which is part of a Personal Area Network.
Related standards or documents: 3GPP TS 24.259: "Personal Network Management (PNM), stage 3".
Security Considerations:
UE is not allowed to include g.3gpp.pne-id media feature tag containing IMEI in the Contact header field of requests and responses of SIP methods other than the SIP REGISTER method except when the request or response is guaranteed to be sent to a trusted intermediary that will remove the g.3gpp.pne-id media feature tag prior to forwarding the request or response to the destination. Other security considerations for this media feature-tag are discussed in subclause 12.1 of IETF RFC 3840 [21].