WO2009030659A1

WO2009030659A1 - Method for communication addressing of mobile subscribers using packet-oriented data transfer for railroad applications

Info

Publication number: WO2009030659A1
Application number: PCT/EP2008/061485
Authority: WO
Inventors: Detlef Kendelbacher; Volker Pliquett; Fabrice Stein
Original assignee: Siemens Aktiengesellschaft
Priority date: 2007-09-03
Filing date: 2008-09-01
Publication date: 2009-03-12
Also published as: DE102007041959B4; DE102007041959A1

Abstract

The invention relates to a method for the communication addressing of mobile subscribers using packet-oriented data transfer for railroad applications. The invention is based on the object of creating dynamic address management for the mobile data applications of the railroad, which takes into consideration changing communication relationships between mobile and stationary facilities, changing packet addresses of the communication partners, maintenance, service, expansions of the system, the required real time behavior, and the special boundary conditions and limitations of the radio resource. These requirements are achieved by the dynamic address management according to the invention. The method according to the invention is provided for applications utilizing mobile data transfer in the area of railroads. It is explained by way of the example provided by the European Train Control System, ETCS. However, the method may further be utilized for any rail services using mobile data transfer.

Description

description

Method for communication addressing mobile subscribers using packet-oriented data transmission for railway applications

For data transmission between mobile and fixed subscribers by means of mobile networks, such as GSM, more and more packet-oriented data services, such as GPRS are used. These data services are characterized by high resource efficiency, since they only load the radio channel when data is actually to be transmitted. Even with the railway operators there are efforts to use more packet-oriented data services for various applications in the railway's GSM mobile networks to exploit the scarce radio resources more effectively. A rail application is the European Train Control System (ETCS), a European standardized system for train control and train control at the railways, with the aim of ensuring the interoperability of train traffic across borders. The ETCS uses GSM mobile radio in Level 2 and 3 and currently transmits train control data via connection-oriented data channels. Since the data throughput is very uneven in ETCS journeys and the radio channels are permanently occupied, the resource efficiency is low. At transport hubs, the available frequencies of the train in the GSM-R network become scarce when using multiple voice and data services. An integration of other rail services in the GSM-R mobile network is limited.

Packet oriented data services such as GPRS use packet-address based connectionless communication instead of telephone numbers and connection-oriented channels. cation, in which individual data packets are transmitted. Mobile and stationary subscribers require packet addresses for data exchange, eg IP addresses, instead of telephone numbers. The structure of packet addresses depends on the used packet-oriented data service. The packet addresses can be assigned temporarily due to a limited address range - dynamic addressing.

The dynamic allocation of packet address addresses places special demands on mobile data communication, since the addresses of mobile and stationary subscribers may change, for example after a re-login to the mobile radio network. In order to ensure permanent accessibility of mobile and physical subscribers, under the conditions of a limited address stock, e.g. IP4, a dynamic assignment of nodes and packet addresses necessary. The dynamic addressing of users in railway applications places additional demands on these rail services. For example, the addresses of vehicles and line centers may change during ETCS operation.

It was an object of the invention to provide for the mobile data applications of the railways a dynamic address management, changing communication relationships between mobile and fixed devices, changing packet addresses of the communication partners, maintenance, repair, extensions of the system, the necessary real-time behavior and the special constraints and limitations the radio resource.

These requirements are solved by the dynamic address management according to the invention. The inventive method is for applications that mobile data transmission in Area of railways use, provided. It is explained using the example of the European Train Control System ETCS. However, it is also usable for any rail services using mobile data transmission. The abbreviation RBC - Radio Block Center, which derives from the ETCS, is representative of stationary facilities for data transmission, while the abbreviation FZG - Fahrzeug - is used to represent mobile devices for data transmission. The destination RBC is the fixed entity with which a mobile subscriber must communicate as part of the train service. With the movement of the mobile subscriber over the railway line, the responsibility of the track-side entity can change, so that a change of the destination RBC - RBC handover - and thus a change in the communication connection is required. The ETCS address provides a means of addressing participants at the application level. It can be replaced in other rail services by a corresponding orbital service specific user address or subscriber identifier.

For dynamic address management, the data transfer between mobile and stationary subscribers is extended by several components and functions:

1. Address center - ADZ

The ADC acts as a central stationary instance for the determination of packet addresses of communication authorities - central information. It contains a memory that contains a dynamic allocation of ETCS addresses to packet addresses. This memory is updated regularly. FZG and RBC with communication needs can contact the ADZ to get information about the packet address of a communication partner. The ETCS address - ETCS ID - the desired communication partner to the ADZ and supplied by the ADZ whose current packet address. For the ADZ, the only instance in the mobile network is the requirement to be reachable under a static address. This can be realized by one or more permanently assigned packet addresses. Alternatively, a name service may be used to address the ADF. The ADZ address is known to all participants of the railway service, which is technically realized, for example, by project planning.

For practical use, the ADC should be designed to be redundant, for example, with several fixed packet addresses to meet the high availability requirements that are placed on a central facility in railway operations. If necessary, the mobile network several ADF can be set, for example, each rail operator a to optimize the communications ^¬ routes. In this case FZGe must have additional information of the currently competent ADZ or contact different ADZs one after the other or in parallel for their inquiries. Technically, an ADF can be integrated if necessary into a RBC, so that the one or more RBCs zusätz ^¬ Lich take the ADF function.

2. Memory and management functions

RBC and optional FZG are extended with additional memory and management functions for address management. RBC receive memory and functions for managing dynamic address data of known FZG and RBC. The data is always updated when a) new packet addresses are assigned to FZG, eg when an FZG is added to the ETCS system b) new packet addresses are assigned to RBC, eg after Maintenance work .

With the provision of these data, communication to known FZG and other RBCs can take place on RBC's initiative. Furthermore, RBC can use this address data to provide information to FZG about required parcel addresses.

Optionally, FZG can be expanded to include storage and RBC dynamic address data management capabilities. The local storage of RBC address data can be the

Speed up communication with RBC, because it does not require you to run setup logs.

3. Communication relations

For the application of dynamic address management, additional communication relationships between different instances are required in addition to the application communication:

a) FZG - ADZ

The communication between FZG and ADZ serves to determine the package address of the RBC responsible for the FZG. The vehicle transmits to the ADC the ETCS address of the RBC and receives the current packet address of the RBC.

b) FZG - RBC

Regardless of the application communication, further communication takes place between FZG and RBC. This communication is used to determine the packet address of the currently responsible RBC destination RBC. At the initiative of the FZG, a request is made for the unknown packet address of the destination RBC in a RBC with a known packet address. Based on the transferred ETCS address, the RBC determines the Packet address of the target RBC, usually the neighbor RBC, and deliver it to the FZG.

c) FZG - Target RBC Parallel to the application communication can optionally be an additional communication between FZG and destination RBC for the purpose of transmitting the ETCS addresses and packet addresses for multiple adjacent RBC to the FZG, so that these addresses are immediately available locally when communication needs - vehicle -Adresscache.

d) RBC - RBC

The communication between RBC provides for the distribution of the currently valid address data, namely ETCS addresses and associated packet addresses, to a defined distribution circuit of RBC. The distribution circuit usually consists of the neighbor RBC and can be flexibly defined for each RBC. Each RBC supplies the address data of all known vehicles and RBC to all RBC in the distribution circuit. By storing and regularly updating the current communication addresses of known FZG and RBC, the RBCs are able to initiate communication with known FZG and RBC, as well as provide parcel address information to FZG.

e) RBC ADZ

All RBCs belonging to an ADZ provide up-to-date address data via known RBC and optionally via known FZG to the ADZ. With this communication, the address database in the ADZ is kept up to date, so that the

ADZ is always able to deliver current packet addresses from RBC and optionally from FGZ to requesting instances.

4. Communication protocols Various communication protocols are introduced for requesting packet addresses - setup protocols - and for distributing packet addresses - update protocols.

If necessary, the setup logs are executed before the actual application communication in order to get the current packet address of the mobile or fixed communication partner. They can run both on the initiative of stationary and mobile participants. Real-time requests are made to these protocols.

The update logs are executed continuously and largely independent of the application communication. They run between fixed and mobile participants without

Real-time requirements, i. with low priority, from and synchronize existing information about current addresses of subscribers. The update logs can work both cyclically and event-driven. To store the address data, e.g. After failures or maintenance, to be able to synchronize, a complete transfer of the present address information is required - no delta transfer.

Setup logs are available in two forms:

a) primary setup protocol:

This protocol is used by mobile and / or fixed subscribers for requesting unknown packet addresses in known subscribers. The application takes place, for example, when an FZG wants to establish a communication relationship with an RBC with an unknown packet address, for example for the purpose of RBC handover, and in the local Database in the FZG the package address of the searched RBC does not exist. Using the primary setup protocol, the FZG makes a request to the destination RBC's packet address at a RBC with a known packet address. The FZG transfers the ETCS address of the destination RBC and receives its packet address if this information is available.

b) secondary setup protocol:

This protocol is mobile and / or fixed

Participants used to request unknown packet addresses at the ADZ. Its application occurs, for example, when an FZG wants to establish a communication relationship with an RBC of unknown packet address, e.g. for the purpose of new inclusion in the ETCS, and neither in the local database in the FZG the required IP address exists, nor by application of the primary setup protocol, the searched IP address could be provided. By means of the secondary setup protocol, the FZG makes a request to the ADZ for the packet address of the searched RBC. The FZG hands over the ETCS address of the searched RBC and receives its packet address, if this information is available.

If a mobile or stationary subscriber with an unknown packet address requires communication, the primary setup protocol is first used to determine the unknown IP address using a known subscriber address. If the request is unsuccessful using the primary setup protocol, the secondary setup protocol will be used to request the desired packet address from the ADF.

Update logs are available in three forms: a) ADZ update protocol:

The ADZ update protocol is used to update the packet address database in the ADZ. Each RBC transmits to the ADZ the ETCS addresses and the packet addresses of all registered RBCs. Optionally, the ETCS addresses and the packet addresses of the FZG registered in the RBC are also transmitted to the ADZ. The ADZ update protocol ensures that contents and changes in the address database of the fixed subscribers are continuously transmitted to the ADZ, e.g. Changes in RBC

Address database when establishing a new communication to a FZG. This ensures that the central information service always has the current address information.

In a special embodiment of the method according to the invention, the packet addresses of the RBC can be permanently assigned in the transmission network. In this case, no online update of the RBC addresses in the ADZ is required at runtime of the system, and the ADZ update protocol can be executed offline in this case, e.g. by designing the ADZ.

b) RBC update protocol:

The RBC update protocol is used to exchange address ^¬ information between stationary participants. Neighboring RBCs continually exchange content and changes in their local address database to synchronize their data status. By means of the RBC update protocol, the packet addresses and ETCS addresses of the FZG registered in one RBC are transmitted to the neighboring RBC. Furthermore, the current packet addresses registered in the RBC and the ETCS addresses can also be reported by the RBC to the neighboring RBC. The exchange of addresses can be up a fixed range of RBC, eg, only direct neighbor RBC, to reduce the amount of information. The RBC update protocol distributes known FZG and optionally RBC address information along the route. If necessary, the RBCs can then establish links with FZG and RBC or provide address information.

In a specific embodiment of the method according to the invention, the packet addresses of the RBCs can be fixedly assigned, e.g. by projecting. In this case, no online update of the RBC addresses between the RBCs is required during runtime of the system, and the RBC update protocol can be limited to the distribution of FZG addresses.

c) FZG update protocol:

The FZG update protocol is used to update the address database in mobile subscribers. It runs in the background while an FZG exchanges data with an RBC as part of the application communication. The RBC uses the FZG update protocol to transmit to the FZG all RBC packet and ETCS addresses stored in its local database. These are expediently the addresses of neighboring RBCs. With this information, the FZG will be able to immediately find the current RBC handover address of the next target RBC in its local database and establish a new communication relationship. The use of the FZG update protocol is optional and requires the management of local data storage in the FZG. With Nutz speeds up between FZG and RBC - address cache.

As a further protocol option, the transmission of the FZG addresses stored in the RBC to the FZG is possible if a direct communication between FZG is provided. The invention will be explained in more detail in practical procedures using GPRS as a parcel service with reference to the figures. In the drawings show:

Fig. 1: An overall view of the data connections of

Participant, Fig. 2: the communication from the mobile to the fixed

Participants, Fig. 3: the communication from stationary to mobile

Subscriber, Fig. 4: the communication from the mobile to the fixed

Attendees,

5: the communication from the stationary to the mobile subscriber,

6 shows the sequence of an RBC update protocol, and FIG. 7 shows the sequence of an FZG update protocol

1. Establishment of the communication from the mobile to the stationary subscriber with reference to FIGS. 2 and 4

For ETCS new admissions and RBC handovers, the FZG - RBC communication is established on the initiative of the FZG. FZG and RBC are identified in the ETCS with unique ETCS addresses. The ETCS address of the respective destination RBC will be announced to the FZG during its journey over the ETCS route. For example, the transmission of the address of the destination RBC to the FZG can be done by means of balises. For the data exchange between FZG and RBC via GPRS, a valid IP address is required as the packet address of the current target RBC. To determine the required IP address of the target RBC in the vehicle, a three-stage procedure is carried out, which is the same for all operational scenarios. Level 1: Based on the ETCS address of the target RBC is stored in the local database of the

FZG searched for the associated IP address. If an entry exists, the communication with the stored IP address is established. The implementation of the next two

Steps are omitted in this case. If there is no entry or no local database, or the communication fails due to an outdated IP address, it continues with level 2.

Stage 2: With the known IP address of the last contacted RBC, the FZG executes the primary setup protocol. This is a query of the searched IP address in a known RBC - usually the neighbor RBC. If the RBC can select the required IP address from its local database, it is transmitted to the FZG. The FZG establishes the connection to the destination RBC with the transmitted IP address. If the communication to the target RBC is successful, stage 3 is no longer performed. If the neighboring RBC can not deliver the IP address you are looking for, or the connection to the target RBC fails.

Level 3: If levels 1 and 2 are unsuccessful, the secondary setup protocol is executed by the FZG as a fallback procedure. The FZG requests the searched IP address at the ADZ. The address of the ADC is known in all FZGen - configured - and can therefore be used at any time. Using the secondary setup protocol, the FZG passes the ETCS address of the destination RBC to the ADF. The ADZ then transmits the corresponding current IP address to the FZG. With the transmitted IP address, the FZG establishes a connection to the destination RBC.

2. Establishment of communication from stationary to mobile Participants (Figures 3 and 5)

In the ETCS the communication FZG - RBC can also be established on the initiative of the RBC. If the RBC has already had communication with the FZG in the past, its IP address is

Address registered in the RBC. If no previous communication took place or the IP address of the FZG has since been changed, e.g. after parking the vehicle, an address inquiry by the RBC is necessary. For the address determination in the RBC, a three-stage procedure is provided analogous to the FZG, which is the same for all operational scenarios.

Level 1: The ETCS address of the FZG is used to search for the associated IP address in the local database of the RBC. If an entry exists, the communication with the stored IP address is established. The implementation of the next two stages is omitted in this case. If there is no entry or the communication fails due to an outdated IP address, it continues with level 2.

Stage 2: The RBC polls the searched IP address on a RBC with a known IP address - Neighbor RBC. To do this, the RBC applies the primary setup protocol. If the neighboring RBC can select the required IP address from its local database, it is transmitted to the RBC. The RBC establishes the connection to the FZG with the transmitted IP address. If the communication to the FZG is successful, the execution of stage 3 is omitted. If the neighboring RBC can not deliver the searched IP address or if the connection to the FZG fails, it continues with level 3.

Level 3: If levels 1 and 2 are unsuccessful, If necessary, run the secondary setup protocol. The RBC requests the requested IP address at the ADZ. The address of the ADC is known in all RBCs - configured - and can therefore be used at any time. Using the secondary setup protocol, the RBC passes the destination RBC's ETCS address to the ADF. The ADZ then transmits the corresponding current IP address to the RBC. With the transmitted IP address, the RBC establishes a connection to the FZG.

3. Updating the address database in the FZG

The optional local address database in the FZG contains RBC's ETCS and IP addresses. These addresses are updated by the FZG update protocol. This optional protocol will be executed when the FZG communicates with the responsible RBC for ETCS data transmission. The transmission of the address data can take place with a lower priority than the transmission of the ETCS train control data. Multiplexing the data in the transport layer of the standardized EURORADIO protocol with the address data of the FZG update protocol is possible. The FZG update protocol updates the addresses of all neighbor RBCs in FZG. As a result, these addresses are immediately available onboard during the RBC handover and need not be requested via setup protocols at the time the connection is established. The sequence of the FZG update protocol is shown in FIG.

4. Updating the address database in the RBC

The address database in the RBC contains the ETCS and IP addresses of all FZGs communicating in the area of the RBC and the neighboring RBC as well as the ETCS and IP addresses of the RBC and the neighboring RBC. The RBC update log synchronizes the datasets adjacent RBC by transmitting the stored FZG and RBC addresses between neighbor RBCs. The transfer of addresses can be restricted to FZG and RBC in a defined environment in order to optimize the data volume. By way of example, only the addresses of the FZG communicating directly with the RBC are transmitted to the direct neighbor RBC. When setting up a new communication with a FZG its ETCS and IP address is stored in the address database of the RBC. The RBC update protocol continues to distribute the address information of the FZG to the neighboring RBC. The transmission can take place via landline communication resources between the RBCs that already exist for the ETCS communication. The RBC update protocol must ensure that even after a RBC has failed, its database is re-synchronized with the neighboring RBC. The flow of the RBC update protocol is shown in Fig. 6 - right side.

5. Updating the address database in the ADZ

The address database in the ADZ contains the ETCS and IP addresses of all RBCs in a specified area. Optionally, the ETCS and IP addresses of all FZG can be managed in a defined area. The area size is freely selectable; For example, an ADC may be responsible for a country.

To ensure that the ADZ can provide correct information about requested addresses at any time, its address database must be kept up to date using the ADZ update protocol. This can be done either online via online data communication RBC → ADZ or offline via configuration ADZ.

When the ADZ is updated online, the ADZ update log is executed between each RBC in the specified area and the ADF. The protocol transmits hold the local address database of the RBC to the ADZ. Since address information, for example the current IP address of a communicating FZG, can be reported by several RBCs to the ADZ, it is expedient to supplement the address information with information on actuality, for example by a time stamp, so that the ADZ always has the most up-to-date Information stand from the messages of the RBC can select. The sequence of the ADZ update protocol is shown in Fig. 6 - left side.

The particular advantage of the method according to the invention is that it can be used for all railway services for data transmission in IP-based networks. Thus, the railways are able to tap into the potential of packet-oriented data services in the GSM-R.

The process can be integrated into existing ETCS systems while maintaining the current standard - EURORADIO. Furthermore, existing standards for data transmission in railway services for the application of the method can be easily extended.

With three hierarchical levels of functionality for establishing new communication links, the process provides a robust, simple and secure solution for discovering current IP addresses under all operating conditions.

The required setup and update logs are simple and resource efficient. Their integration into the ETCS and other rail services can be cost-effective and low-risk.

The wireless setup and update protocols between FZG and RBC can be carried out without changing the EURORADIO standard together with the transmission of the ETCS data. For a shared use of EURORADIO protocols only needs to be assigned a new service ID. Alternatively, a protocol-separated transmission for ETCS and setup / update data done.

The required storage and management functions can be easily integrated into existing systems, for example integration of an ADC into an RBC. The additional investment needs are relatively low.

When the method is used, previous application addressing methods can be used unchanged in the ETCS, for example transmission of ETCS addresses of the RBCs from balises. It is not necessary to configure the IP addresses of RBC or FZG.

The address management according to the method described is open and expandable.

New FZG and RBC are automatically integrated into the process.

The method can be used in local and temporal mixed operation with connection-oriented channels.

Claims

claims

A method for communication addressing mobile subscribers using packet-oriented data transmission for rail applications, in which mobile and stationary subscribers for data exchange require packet addresses and the structure of packet addresses depends on the used packet-oriented data service and temporarily awarded due to a limited address range, characterized in that For dynamic address management, the data transfer between mobile subscribers - vehicle (FZG) - and fixed subscribers - Radio Block Center (RBC) - is extended by the following components and functions: - Address center (ADC), which acts as a central stationary instance for the determination of packet addresses of communication instances and memory contains a dynamic allocation of system addresses, eg ETCS addresses, contains at packet addresses and is updated regularly, whereby FZG and RBC with

Communication requirements can contact the ADZ to obtain information about the packet address of a communication partner and the system address of the desired communication partner is passed to the ADZ and supplied by the ADZ whose current packet address,

Memory and management functions wherein RBC obtains memory and functions for managing dynamic address data of known FZG and RBC and wherein the data is updated whenever a) FZG are assigned new packet addresses, e.g. at

Include a FZG in the ETCS system, b) assign RBC new packet addresses, e.g. to

Maintenance work, communication relations between a) FZG - ADZ, wherein the communication of FZG and ADZ is used to determine the packet address of the RBC responsible for the FZG and the vehicle transmits to the ADZ the ETCS address of the RBC and receives the current RBC packet address, b) FZG - RBC , Wherein, independently of the application communication, a further communication between FZG and RBC for determining the packet address of the currently competent

RBC - target RBC - takes place, c) FZG - target RBC, wherein parallel to the application communication optional additional communication between FZG and target RBC for the purpose of transmitting the ETCS addresses and

Packet addresses for several neighboring RBCs to the FZG, d) RBC - RBC, whereby the communication between RBC for the distribution of the currently valid address data - ETCS-

Addresses and associated packet drives - providing to a defined distribution circuit of RBC, e) RBC - ADZ, all RBCs associated with an ADZ providing current address data via known RBC and optionally via known FZG to the ADZ, communication protocols, whereby communication protocols for requesting packet addresses, Setup logs - and for distributing packet addresses - update logs - are executed, where the setup logs are executed before the actual application communication if necessary, to get the current mobile or fixed communication partner's packet address, and wherein the update protocols are executed continuously and largely independently of the application communication - without real-time requirements, ie with low priority - and distribute existing information about current addresses of subscribers.

2. The method according to claim 1, characterized in that the ADZ is realized by one or more firmly assigned packet addresses.

3. The method according to any one of the preceding claims, characterized in that a name service for addressing the ADZ is used.

4. The method according to any one of the preceding claims, characterized in that the ADZ is designed to be redundant for practical use.

5. The method according to any one of the preceding claims, characterized in that several ADCs are set up in the mobile network.

6. The method according to any one of the preceding claims, characterized in that an ADZ is integrated into a RBC, so that an RBC can additionally take over the ADC function with.

7. The method according to any one of the preceding claims, characterized in that the FZG be extended by a memory and functions for managing dynamic address data from RBC.

8. The method according to any one of the preceding claims, characterized in that at the initiative of the FZG a request for the unknown packet address of the destination RBC takes place at a RBC with a known packet address and the RBC based on the transferred system ETCS address the packet address of the destination RBC, usually the neighboring RBC, determined and delivers this to the FZG.

9. Method according to one of the preceding claims, characterized in that, in a communication of the RBC, the distribution circuit normally consists of the neighbor RBC and can be flexibly defined for each RBC, each RBC thereby defining the

Address data of all known vehicles and RBC supplies to all RBC in the distribution circuit, and by storing and regularly updating the current communication addresses known FZG and RBC, the RBC are able to initiate the communication with known FZG and RBC, as well as packet address information to FZG deliver.

10. The method according to claim 1, characterized in that setup protocols run both on the initiative stationary, as well as mobile participants and are placed on these protocols real-time requirements.

11. The method according to claims 1 and 10, characterized in that the setup protocol is pronounced as a primary setup protocol that is used by mobile and / or fixed participants for the request unknown packet addresses in known participants.

12. The method according to claim 11, characterized in that when an FZG wants to establish a communication relationship with an unknown packet address RBC, e.g. for RBC handover, and in the local database in FZG the packet address of the searched RBC is not present, by means of the primary setup protocol by the FZG at a RBC with known packet address a request for the packet address of the target RBC is made and the FZG the system -Address the destination RBC and receives its packet address, if this information is present.

13. The method according to any one of claims 1 and 10 to 12, characterized in that the setup protocol is formed as a secondary setup protocol that is used by mobile and / or fixed participants for the request unknown packet addresses in the ADZ.

14. The method according to claim 13, characterized in that when an FZG wants to establish a communication relationship with a RBC with an unknown packet address, e.g. for the purpose of new inclusion in the ETCS, and neither in the local database in the FZG the required IP address is present, nor by using the primary setup protocol, the searched IP address could be provided by means of the secondary setup protocol by the FZG at the ADZ a request for the Package address of the searched RBC is provided and the FZG to the ETCS address of the searched RBC hands over and its package address, if this information is available receives.

15. The method according to any one of claims 1 and 10 to 14, characterized in that when a mobile or stationary subscriber with an unknown packet address needs to communicate, first the primary setup protocol is used to determine the unknown IP address using a known subscriber address and if the secondary setup protocol is used in case of unsuccessful request by the primary setup protocol, to request the desired packet address from the ADZ.

16. The method according to claim 1, characterized in that update protocols can operate both cyclically and event-controlled, wherein a complete transmission of the present address information is required - no delta transmission - to the address data inventories, e.g. after failures or maintenance, to be able to synchronize.

The method of claims 1 and 16, characterized in that the update protocol is an ADZ update protocol and is for updating the packet address database in the ADZ, each RBC communicating to the ADZ the ETCS and packet addresses of all registered RBCs.

18. The method according to any one of claims 1 and 16 to 17, characterized in that the packet addresses of the RBC are permanently assigned in the transmission network, so that no online update of the RBC addresses in the ADZ is required at runtime of the system and the ADZ update protocol can be executed offline, eg by designing the ADZ.

19. Method according to claims 1 and 16, characterized in that the update protocol is an RBC update protocol and is used to exchange address information between fixed subscribers.

20. The method according to claims 1 and 19, characterized in that adjacent RBC continuously exchange contents and changes in their local address database with each other to synchronize their data status, that by means of the RBC update protocol, the packet and ETCS addresses of the in a RBC Registered FZG are transmitted to the neighboring RBC, and that the current packet and ETCS addresses registered in the RBC are reported by the RBC to the neighboring RBC.

Method according to claims 1 and 19 to 20, characterized in that the exchange of addresses to a fixed range of RBC, e.g. only direct neighbor RBC, is limited to reduce the amount of information.

22. The method according to claims 1 and 19 to 21, characterized in that by the RBC update protocol known address information of FZG and optionally of RBC are distributed along the route, so that the neighboring RBC therewith, if necessary, connections to FZG and RBC or provide address information.

23. The method according to claims 1 and 19 to 22, characterized in that the packet addresses of the RBC are assigned permanently, for example by projecting, so that at runtime of the system no online update of the RBC addresses between the RBC required and the RBC update log can be restricted to the distribution of FZG addresses.

24. The method of claim 1 and 16, characterized in that the update protocol is a FZG update protocol and the updating of the address database in mobile subscribers, wherein the protocol is executed in the background, while an FZG exchanges data with a RBC in the context of application communication.

25. The method according to claim 24, characterized in that the RBC transmitted by FZG update protocol to the FZG the vehicle contents of all stored in its local database packet and ETCS addresses of RBC, wherein the FZG is enabled with this information to immediately find the current RBC handover address of the next target RBC in its local database and establish a new communication relationship.

26. The method according to claims 24 and 25, characterized in that the use of the FZG update protocol is optional and requires the management of local data storage in the FZG, with the use of this protocol, the construction of new communication links between FZG and RBC is accelerated - address cache.

27. The method according to any one of claims 24 to 26, characterized in that the transmission of the stored in the RBC FZG addresses to the FZG takes place as a protocol option, if a direct communication between FZG is provided.