## 3 Description of Railway Identity Management Service  
The proposed Railway Identity Management (RIM) service can be used for the following:  
* The registration and deregistration of FRMCS UE:
* The registration and deregistration of an FRMCS UE's functional identity:
* The registration and deregistration of an FRMCS user's functional identity:
* The retrieval of registered UE identity(ies), UE functional identity(ies), user identity(ies), and user functional identity(ies):
* Subscriptions to notifications about changes in the registration status of UE identity(ies), UE functional identity(ies), user identity(ies), and user functional identity(ies). Figure 4: Flow of registration for a “Cab radio” FRMCS UE. The service's application programming interfaces (API) are bound by the Hypertext Transfer Protocol (HTTP) and are designed using the REpresentational State Transfer (REST) architectural style. Figure 5 shows the structure of the RIM service resource Uniform Resource Identifiers (URIs), where the RIM service is registered in a service directory. The userEquipments resource represents a list of all of the registered UEs. An HTTP GET method retrieves the list of registered UE identities, and an HTTP POST method creates a new ueID resource. The userEquipments resource is represented by a ueList data structure, which is a structured collection of UE information (uenInfo) lists and a self-referring Uniform Resource Locator (URL). The ueID resource refers to individually registered UE information and it is represented by uenInfo, which is a structure comprising the UE address, UE type, UE presence status, and a self-referring URL. The UE presence status shows the UE context status in terms of activity (available, busy, railway emergency communication, etc. ), placeType (train, station, office, etc. ), placeProperties (the place where the user is currently), timeOffset (the number of minutes from the Coordinated Universal Time--UTC), location (direction, destination, track section), activeApplications (describes the active applications), etc. The presence information is provided by the FRMCS system. An HTTP GET method retrieves information about the individual UE, and an HTTP DELETE method deletes individual UE registration. Figure 6 shows a scenario in which a new ueID resource is created, where information about individually registered UE is retrieved, and where UE is deregistered using an application. To register a new UE, an application creates a new ueID resource under http://\(\backslash\)apiRoot\(\backslash\)/rim/v1/userEquipments. To retrieve information about a registered UE, to update information, or to deregister a UE, an application sends a request under http://\(\backslash\)apiRoot\(\backslash\)/rim/v1/userEquipments\(\backslash\)(ueID). The newINs resource represents a list of all of the registered functional identities on an individual UE. An HTTP GET method retrieves the list of registered functional identities of given UE, and an HTTP POST method registers a new functional number for given registered UE. The resource is represented by the ueFNlist data structure, which is a structure of UE functional numbers and a self-referring URL. The ueFNID resource refers to individual UE functional number information and it is represented by ueFNinfo, which is a structure of the UE functional number, UE functional number context status, and a self-referring URL. The allowed HTTP methods are GET, which retrieves information about an individual UE functional number, and DELETE is used to unregister a UE functional number. Figure 5: The structure of the RIM service resource URIs. The users resource represents a list of all of the registered users on a given registered UE. An HTTP GET method retrieves the list of all of the registered users on an individual UE, and an HTTP POST method is used to register a new user on given registered UE, where the method body contains user credentials.